Portable general timestamp format, not 2038-limited

P

Paul Rubin

Martin Gregorie said:
<picky_mode>
Nope - you referenced leap seconds, not TAI and not that URL

Oh whoops, I thought I put that url further up in the thread.
I remember grumbling to myself about having to look for it twice.
Maybe I'm just confused. Anyway it's pretty interesting stuff,
as is the Wikipedia article someone else linked to.
 
S

sla29970

Oh whoops, I thought I put that url further up in the thread.
I remember grumbling to myself about having to look for it twice.
Maybe I'm just confused. Anyway it's pretty interesting stuff,
as is the Wikipedia article someone else linked to.

Keep in mind that TAI is not legal time anywhere. It is also not
practical, for the TAI now is not available until next month.
From a legal standpoint, either UTC or GMT (or both, if you read
different languages in the EU documents) as kept by your national
metrology lab is is the official time. Despite the way the math looks
and the way the physics seems like it ought to dictate, TAI is derived
from UTC, not the other way around. The national metrology labs are
tasked to provide GMT or UTC as part of their charter, so that is
*procedurally* the primary time scale.

Also note the "discussion" link on wikipedia's TAI page before
believing it too much.
 
M

Martin Gregorie

Paul said:
Oh whoops, I thought I put that url further up in the thread.
I remember grumbling to myself about having to look for it twice.
Maybe I'm just confused. Anyway it's pretty interesting stuff,
as is the Wikipedia article someone else linked to.
>
Thinking of interesting date & time related stuff, there's another
document I remember seeing a while back - probably around early '98. It
was an ASCII configuration file that contained to rules for mapping
human readable dates & times to UNIX timestamps after taking account of
changes of calendar (e.g. the switch between Julian and Gregorian
calendars), the introduction of daylight saving time, etc. I remember
that it was mostly comment interspersed with mapping rules and that the
comments were vast and fascinating, often including copies of e-mail
threads.

The file was part of a Linux distro, probably Debian. Some time later,
after I set up my first Linux system, I went looking for it without
success, probably because by that time (RedHat 6.2) the date mapping
rules had become encoded as some sort of binary rule set.

I'd very much like to know where I could find a copy of that file.
 
P

Paul Rubin

Keep in mind that TAI is not legal time anywhere. It is also not
practical, for the TAI now is not available until next month.

If you mean they don't announce the average of the 350 atomic clocks
til a month later, well swell, but you can get sub-microsecond
accuracy from GPS references.
different languages in the EU documents) as kept by your national
metrology lab is is the official time.

According to <http://en.wikipedia.org/wiki/UTC>, UTC is derived from
TAI. And according to the linked article that I think you mention,
comparing clocks on different contents gives uncertainty in the 10-50
ns range.
The national metrology labs are tasked to provide GMT or UTC as part
of their charter, so that is *procedurally* the primary time scale.

Here we see the difference between UTC (the one synchronized to TAI)
and NIST UTC:

http://tf.nist.gov/pubs/bulletin/nistutc.htm

it's always within 20 nsec. This seems like the kind of correction
that can be applied after the fact. Anyway GPS time is probably
further out than NIST.

The difficulty/impossibility of computing intervals on UTC because of
leap seconds suggests TAI is a superior timestamp format.
 
L

Leo Kislov

The difficulty/impossibility of computing intervals on UTC because of
leap seconds suggests TAI is a superior timestamp format.

If you care about intervals you'd better keep timestamps in SI seconds
since some zero time point (just like OP wanted). TAI timestamps are
pretty useless IMHO. They need to be converted to decimal/float for
interval calculations and they don't represent any legal time.

-- Leo
 
S

sla29970

According to <http://en.wikipedia.org/wiki/UTC>, UTC is derived from
TAI.

According to <http://en.wikipedia.org/wiki/TAI>, TAI is a proper time,
but the very first section in the TAI discussion page cites a refereed
paper by the person then in charge of TAI which asserts that is not
true.

As for the primacy of UTC vs. TAI, this is the classical chicken and
egg problem. The bureaucratic reality is opposed to the physical
reality.
it's always within 20 nsec. This seems like the kind of correction
that can be applied after the fact.

It is the nature of horology that *all* clocks need corrections
applied after the fact. The question is whether a given clock and its
time distribution system is good enough for the given application.
The difficulty/impossibility of computing intervals on UTC because of leap seconds suggests TAI is a superior timestamp format.

TAI is a superior time scale for processes on the surface of the earth
which only care about nanosecond precision, but it is not practically
available nor legal nor applicable off the surface of the earth. TAI
is itself corrected after the fact by the issue of TT(BIPMxx).
 
P

Peter J. Holzer

I have a requirement to store timestamps in a database. Simple enough
you might think but finding a suitably general format is not easy. The
specifics are

1) subsecond resolution - milliseconds or, preferably, more detailed
2) not bounded by Unix timestamp 2038 limit
3) readable in Java
4) writable portably in Perl which seems to mean that 64-bit values
are out
5) readable and writable in Python
6) storable in a free database - Postgresql/MySQL

Stick to unix timestamps but store them as a double precision floating
point number. The 53 bit mantissa gives you currently a resolution of
about 200 ns, slowly deteriorating (you will hit ms resolution in about
280,000 years, if I haven't miscalculated). Any language and database
should be able to handle double-precision FP numbers, so that's as
portable as it gets and conversion from/to system time should be
trivial.

If you need to represent milliseconds exactly, you can just multiply the
timestamp with 1000 (and get java timestamps).

hp
 
R

Roedy Green

You cannot accurately compute
the number of seconds between Nixon's resignation and 1800 UTC today,
unless you take into account the leap seconds have been occurred
between then and now.

There are two valid answers to those questions. In a court of law,
say did some document arrive before deadline, you must use civil
time. Arguing leap seconds would not fly.

On the other hand, if you used civil seconds to computer satellite
orbits, tiny errors mount up quickly in the calculation.
 
P

Paul Rubin

Roedy Green said:
There are two valid answers to those questions. In a court of law,
say did some document arrive before deadline, you must use civil
time. Arguing leap seconds would not fly.

I'd say if the deadline is "the document must arrive before noon
on August 9, 2009", that is civil time, including any leap seconds.
We don't know the exact number of seconds until then because
there might be some leap seconds that haven't yet been announced.

On the other hand if the deadline is "the document must arrive
no more than 1 billion seconds after noon on January 20, 2001"
that is an exact number of seconds. We don't yet know the exact
civil time because we don't know about the leap seconds to come.
 
R

Roedy Green

TAI really does seem like the most absolute--if you are a user in
orbit or on Mars, then UTC timestamps will seem pretty meaningless and
artificial.

According to Einstein all time is local time, so perhaps our wish for
a clean UT is a pipedream.

To add to the confusion you have GPS, Loran and Julian day also used
as scientific times.
 
M

Martin Gregorie

Roedy said:
To add to the confusion you have GPS, Loran and Julian day also used
as scientific times.
>
GPS time is UTC time and I'd assume the same is true for Loran. Both are
primarily for navigation and so are on Zulu time, which is another name
for UTC. Zulu is the international radio word for the letter Z.

I've never seen Julian time used outside the world of IBM mainframes.
I'd be interested to know who else uses it.
 
C

CBFalconer

Roedy said:
On 25 Jun 2007 18:46:25 -0700, Paul Rubin
.... snip ...


According to Einstein all time is local time, so perhaps our wish
for a clean UT is a pipedream.

To add to the confusion you have GPS, Loran and Julian day also
used as scientific times.

In summary, time is now defined as a non-continuous function, and
is thus proof against manipulation by most standard algebraic
techniques. Take that :) In fact, it is not even quanticized.
 
P

Paul Rubin

Martin Gregorie said:
GPS time is UTC time

According to Wikipedia,

While most clocks are synchronized to Coordinated Universal Time
(UTC), the Atomic clocks on the satellites are set to GPS time. The
difference is that GPS time is not corrected to match the rotation of
the Earth, so it does not contain leap seconds or other corrections
which are periodically added to UTC. GPS time was set to match
Coordinated Universal Time (UTC) in 1980, but has since diverged. The
lack of corrections means that GPS time remains at a constant offset
(19 seconds) with International Atomic Time (TAI).

http://en.wikipedia.org/wiki/GPS#Ephemeris_and_clock_errors
 
D

Dennis Lee Bieber

According to Wikipedia,

While most clocks are synchronized to Coordinated Universal Time
(UTC), the Atomic clocks on the satellites are set to GPS time. The
difference is that GPS time is not corrected to match the rotation of
the Earth, so it does not contain leap seconds or other corrections
which are periodically added to UTC. GPS time was set to match
Coordinated Universal Time (UTC) in 1980, but has since diverged. The
lack of corrections means that GPS time remains at a constant offset
(19 seconds) with International Atomic Time (TAI).

What is not mentioned is that, as part of the data stream picked up
by GPS receivers, is a term specifying the "correction factor" between
GPS and UTC; so receivers can display UTC time.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/
 
M

Martin Gregorie

Roedy said:
not according to this site that has clocks running on all three.
They are out slightly.

http://www.leapsecond.com/java/gpsclock.htm
>
A useful reference: thanks. Interesting that GPS and Loran are slightly
out from Zulu. I'll ask round and see if this is something that ATP
pilots are aware of: as a glider pilot and GPS user I'd never heard of
it. So far the deviations from UTC are probably not enough to affect
navigation significantly, but I wonder if banks using networks that
timestamp transactions with GPS time know about it. Of course the
deviation can't affect disputes where the timestamps are being used to
decide event sequences within a single network. However, there could be
legal implications if absolute time is important or if the timestamps
are being compared across different networks, e.g SWIFT vs CHAPS or Fedwire.
 
P

Paul Rubin

Dennis Lee Bieber said:
What is not mentioned is that, as part of the data stream picked up
by GPS receivers, is a term specifying the "correction factor" between
GPS and UTC; so receivers can display UTC time.

Oh yes, good point, the article ought to mention that.
 
B

Ben Finney

Martin Gregorie said:
I've never seen Julian time used outside the world of IBM
mainframes. I'd be interested to know who else uses it.

Systems which need to perform date+time computations into the
past. One advantage of Julian time is that it ignores the "1 BC was
immediately followed by 1 AD, there is no 0 AD" hiccup, so Julian time
allows dates to use simple arithmetic to determine the interval.

I know that PostgreSQL at least stores date values in Julian time, for
exactly this benefit.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top