Generate WWVB timecodes for any desired time
Find a file
jepler 07bc678bf7
All checks were successful
Test wwvbpy / build (push) Successful in 1m31s
Merge pull request 'update-pre-commit-etc' (#171) from update-pre-commit-etc into main
Reviewed-on: #171
2025-12-22 04:28:47 +01:00
.forgejo/workflows pre-installed python can't build extensions 2025-12-21 19:45:03 -06:00
docs documentation: Switch to mkdocs 2025-12-13 19:21:30 -06:00
LICENSES Remove adafruit_datetime.pyi 2025-05-27 10:42:25 +02:00
src small tweaks for other type checkers 2025-12-14 10:16:54 -06:00
test Move COVERAGE_INCLUDE to pyproject 2025-12-13 19:22:11 -06:00
.gitignore documentation: Switch to mkdocs 2025-12-13 19:21:30 -06:00
.pre-commit-config.yaml update ruff, pyupgrade 2025-12-21 19:39:21 -06:00
.readthedocs.yaml documentation: Switch to mkdocs 2025-12-13 19:21:30 -06:00
Makefile Run python in developer mode for deprecation warnings 2025-12-21 19:38:23 -06:00
mkdocs.yaml readthedocs requires this name? 2025-12-13 19:26:53 -06:00
pyproject.toml update email address 2025-12-21 19:38:33 -06:00
README.md documentation: Switch to mkdocs 2025-12-13 19:21:30 -06:00
requirements-dev.txt try using uv this way 2025-12-05 13:36:24 -06:00
requirements-doc.txt documentation: Switch to mkdocs 2025-12-13 19:21:30 -06:00
requirements-typing.txt Switch type checking to ty by default 2025-12-14 10:24:31 -06:00
requirements.txt move leapseconddata to requirements-dev 2025-12-05 11:47:08 -06:00

PyPI

Purpose

Python package and command line programs for interacting with WWVB timecodes.

Where possible, wwvbpy uses existing facilities for calendar and time manipulation (datetime and dateutil).

It uses DUT1/leap second data derived from IERS Bulletin "A" and from NIST's "Leap second and UT1-UTC information" page. With regular updates to the "iersdata", wwvbpy should be able to correctly encode the time anywhere within the 100-year WWVB epoch. (yes, WWVB uses a 2-digit year! In order to work with historical data, the epoch is arbitrarily assumed to run from 1970 to 2069.)

Programs include:

  • wwvbgen, the main commandline generator program
  • wwvbdecode, the main commandline decoder program
  • wwvbtk, visualize the simulated WWVB signal in real-time using Tkinter
  • dut1table, print the full history of dut1 values, including estimated future values
  • updateiers, download the latest dut1 data including prospective data from IERS and NIST

The package includes:

  • wwvb, for generating WWVB timecodes
  • wwvb.decode, a generator-based state machine for decoding WWVB timecodes (amplitude modulation only)
  • uwwvb, a version of the decoder intended for use on constrained environments such as CircuitPython.

Development status

The author (@jepler) occasionally develops and maintains this project, but issues are not likely to be acted on. They would be interested in adding co-maintainer(s).

WWVB Timecodes

The National Institute of Standards and Technology operates the WWVB time signal service near Fort Collins, Colorado. The signal can be received in most of the continental US. Each minute, the signal transmits the current time, including information about leap years, daylight saving time, and leap seconds. The signal is composed of an amplitude channel and a phase modulation channel.

The amplitude channel can be visualized as a sequence of (usually) 60 symbols, which by default wwvbgen displays as 0, 1, or 2. The 0s and 1s encode information like the current day of the year, while the 2s appear in fixed locations to allow a receiver to determine the start of a minute.

The phase channel (which is displayed with --channel=phase or --channel=both) consists of the same number of symbols per minute. This channel is substantially more complicated than the phase channel. It encodes the current time as minute-of-the-century, provides extended DST information, and includes error-correction information not available in the amplitude channel.

Usage

For example, to display the leap second that occurred at the end of 1998,

$ wwvbgen -m 7 1998 365 23 56
WWVB timecode: year=98 days=365 hour=23 min=56 dst=0 ut1=-300 ly=0 ls=1
'98+365 23:56  210100110200100001120011001102010100010200110100121000001002
'98+365 23:57  210100111200100001120011001102010100010200110100121000001002
'98+365 23:58  210101000200100001120011001102010100010200110100121000001002
'98+365 23:59  2101010012001000011200110011020101000102001101001210000010022
'99+001 00:00  200000000200000000020000000002000100101201110100121001000002
'99+001 00:01  200000001200000000020000000002000100101201110100121001000002
'99+001 00:02  200000010200000000020000000002000100101201110100121001000002

(the leap second is the extra digit at the end of the 23:59 line; that minute consists of 61 seconds, instead of the normal 60)

How wwvbpy handles DUT1 data

wwvbpy stores a compact representation of DUT1 values in iersdata.json, the format of which is an implementation detail.

Since 2001, NIST has published the actual DUT1 values broadcast, and the date of each change, though it in the format of an HTML table and not designed for machine readability.

NIST does not update the value daily and does not seem to follow any specific rounding rule. Rather, in WWVB "the resolution of the DUT1 correction is 0.1 s, and represents an average value for an extended range of dates. Therefore, it will not agree exactly with the weekly UT1-UTC(NIST) values shown in the earlier table, which have 1 ms resolution and are updated weekly." Like wwvbpy's compact representation of DUT1 values, the real WWVB does not appear to ever broadcast DUT1=-0.0.

For a larger range of dates spanning 1973 through approximately one year from now, IERS publishes historical and prospective UT1-UTC values to multiple decimal places, in a machine readable fixed length format.

wwvbpy merges the WWVB and IERS datasets, favoring the WWVB dataset for dates when it is available. There are some caveats to this, which are mostly commented in the wwvb/updateiers.py script.

The git version of iersdata.json is updated monthly from forgejo actions or with updateiers --dist from within the wwvbpy source tree. However, at this time, releases are not regularly made from the updated information.

A site or user version of the file, wwvb_iersdata.py can be created or updated with updateiers --site or updateiers --user. If the distributed iersdata is out of date, the generator will prompt you to run the update command.

Leap seconds are inferred from the DUT1 data as follows: If X and Y are the 1-digit-rounded DUT1 values for consecutive dates, and X*Y<0, then there is a leap second at the end of day X. The direction of the leap second can be inferred from the sign of X, a 59-second minute if X is positive and a 61-second minute if it is negative. As long as DUT1 changes slowly enough during other times that there is at least one day of DUT1=+0.0, no incorrect (negative) leapsecond will be inferred. (something that should remain true for the next few centuries, until the length of the day is 100ms different from 86400 seconds)

The phase modulation channel

This should be considered more experimental than the AM channel, as the tests only cover a single reference minute. Further tests could be informed by the other implementation I know of, except that implementation appears incomplete.

Testing wwvbpy

Run the testsuite, check coverage & type annotations with gmake.

There are several test suites:

  • testwwvb.py: Check output against expected values. Uses hard coded leap seconds. Tests amplitude and phase data, though the phase testcases are dubious as they were also generated by wwvbpy.
  • testuwwvb.py: Test the reduced-functionality version against the main version
  • testls.py: Check the IERS data through 2020-1-1 for expected leap seconds
  • testpm.py: Check the phase modulation data against a test case from NIST documentation
  • testcli.py: Check the commandline programs work as expected (limited tests to get 100% coverage)