There are a number of GPSDO that include such a UTC time tag feature.
The earliest example I know is the hp 59551A, with 3 time tagging
inputs. I'm told power companies used these products to locate faults
along transmission lines, a clever use of GPS. More info here [1].

See also the Pendulum CNT-91 timestamping counter for SCPI examples of
time capture.

The latest GPSDO from SRS (FS740) includes UTC time tagging. Check the
user manual for their SCPI implementation.

Yes, some mechanical clocks are timed against UTC. But most DIY and
commercial timers in that space already employ GPS for this.

I've used UTC timestamping for mains frequency logging. That too is a
niche application but it makes a good test case because of the unusually
high data rate. It's also a good test case because multiple users on the
same grid can directly compare their raw timestamp files.

There are lots of time formats to choose from. Start with one of the ISO
8601 formats. Another popular one is based on unix time_t: unsigned
non-leap seconds since 1970-1-1 and 9 decimal places of nanoseconds. For
example, right now is 1720810149 and if you add nanoseconds the
timestamp looks like 1720810149.123456789. One problem with that format
is that it looks like an innocent floating point number but even if you
use 64-bit double you lose a couple hundred nanoseconds due to loss of
precision. So some systems output two integers instead, one for seconds,
one for nanoseconds.

Assuming your code is open source, maybe make it easy for the user to
create their own application specific format.

One last note, many vintage telecom related GPS receivers had support
for timestamps. Mostly output (time of day), sometimes input (time
tagging). The feature to note is that they often included a TFOM (time
figure of merit) in their data format. This is kind of important for a
GNSS based device. A smart GPSDO can know pretty well how accurate (at
least to order of magnitude) the timestamps are or aren't. In other
words, it's not so much about the format of the timestamp but the
confidence of the timestamp. Power up, loss of lock (holdover), low
visibility, mobile use can all affect TFOM.

/tvb

[1] http://leapsecond.com/museum/hp59551a/

On 7/12/2024 4:03 PM, Tom Van Baak via time-nuts wrote:

It is curious to talk about standardized time stamps for power company
telemetry.    I spend my days managing the flow of data between sources
and sinks using various electrical grid protocols, and there are at
least 37 different standard ways of specifying the time of a measurement

• and they are not always definitive. For example the DNP3 standard says
  something to the effect of "Leap seconds,  yes we have heard of them.   
  We are not sure what to do about them so it is up to end users to figure
  it out on their own"

-Joe Fitzgerald

Hi Erik,

While one usually is able to achieve it anyway, there is a benefit in
having TAI or UTC time to measurements, in order to correlate with other
measurements being done by other instruments. Usually you can deduce
what would reasonably would be the time by time-stamping the measurement
as it pops over to some other device. However, sometimes you end up not
really knowing, so if you can ensure that you got the right time, it
will indeed help.

However, if getting the right time on the instrument, such that it may
be wrong or not track UTC properly, then you might have a problem. As
always, being able to after the fact correct for incorrect time-stamps
ends up saving data and effort, while not destroying what was originally
captured. That is however a post-processing concern that would help
regardless.

So, I would not discourage you, but to take some care to ensure you get
good time, it becomes another thing to test and verify.

Cheers,
Magnus

On 2024-07-12 18:44, Erik Kaashoek via time-nuts wrote:

Hi,

On 2024-07-12 23:11, Joe Fitzgerald via time-nuts wrote:

This being said, I would like to point out that the IRIG-B profile as it
exist in the IEEE C37.118.1 spec is actually pretty darn good. There are
times when the power-people get it right. I've also seen power-people do
other stuff which isn't good and certainly not careing about
leap-seconds. The NASPI TSTF report of March 2017 have a few fun
illustrations.

Leap seconds create a little fun mess when not dealt properly with when
doing phasor measurements using PMUs. Since the power-grid isn't perfect
50 Hz or 60 Hz, the reference phase can jump and the difference between
phase before or after that jump is caused by the frequency error. This
can cause false warnings down the line, unless you consider the
possibility of leap-second error and you can readily detect it, because
you know the frequency from the second before, as a by-product of the
measurements. The PMUs has a reference phase which should actually
follow TAI and then timestamps that should follow UTC, but that's not
quite how the standard articulate it.

Cheers,
Magnus