Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Portable general timestamp format, not 2038-limited

Reply
Thread Tools

Portable general timestamp format, not 2038-limited

 
 
sla29970@gmail.com
Guest
Posts: n/a
 
      06-26-2007
On Jun 26, 2:17 pm, Paul Rubin <http://(E-Mail Removed)> wrote:
> Martin Gregorie <(E-Mail Removed)> writes:
> > > Same one already given:http://cr.yp.to/proto/utctai.html

> > <picky_mode>
> > Nope - you referencedleap 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.


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.

 
Reply With Quote
 
 
 
 
Martin Gregorie
Guest
Posts: n/a
 
      06-26-2007
Paul Rubin wrote:
> Martin Gregorie <(E-Mail Removed)> writes:
>>> Same one already given: http://cr.yp.to/proto/utctai.html

>> <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.
>

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.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      06-28-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> 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.

> >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.


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.
 
Reply With Quote
 
Leo Kislov
Guest
Posts: n/a
 
      06-28-2007
On Jun 27, 10:51 pm, Paul Rubin <http://(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
sla29970@gmail.com
Guest
Posts: n/a
 
      06-28-2007
On Jun 27, 10:51 pm, Paul Rubin <http://(E-Mail Removed)> wrote:
> 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).


 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      07-01-2007
On 2007-06-22 20:33, James Harris <(E-Mail Removed)> wrote:
> 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



--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-01-2007
On 25 Jun 2007 18:46:25 -0700, Paul Rubin
<http://(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      07-01-2007
Roedy Green <(E-Mail Removed)> writes:
> >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.


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.
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-01-2007
On Tue, 26 Jun 2007 13:04:50 +0100, Martin Gregorie
<(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>TAI? Care to provide a reference?


see http://mindprod.com/jgloss/tai.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-01-2007
On 25 Jun 2007 18:46:25 -0700, Paul Rubin
<http://(E-Mail Removed)> wrote, quoted or indirectly quoted
someone who said :

>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.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Portable general timestamp format, not 2038-limited James Harris Python 82 07-12-2007 02:16 PM
Portable general timestamp format, not 2038-limited James Harris Java 77 07-12-2007 02:16 PM
Measuring running time in a general + portable way upperclass C Programming 20 04-27-2007 09:47 AM
Portable Python - free portable development environment ! perica.zivkovic@gmail.com Python 7 01-13-2007 11:19 AM
portable (VHDL) vs. non-portable (altera LPM) approaches to signed computations Eli Bendersky VHDL 1 03-01-2006 02:43 PM



Advertisments