TAI is an international time standard. It has a number of technical
advantages over UTC. One of these advantages is that it doesn't have
any silly truck with leap seconds.

Dan Bernstein has defined a time format called TAI64 which is based on
TAI. The format is very simple. TAI64 is almost compatible with Unix
epoch time. TAI64 has a resolution of one second and a range of about
300 billion years.

Bernstein has a small, good-quality library of code for manipulating
TAI64 values and for converting them to and from UTC or unix epoch
time. The library is in the public domain, so there can't be any
license or copyright objection to including it in Perl.

TAI64 has one-second precision, but there are extensions to it,
TAI64N and TAI64A, with nanosecond and attosecond precision. libtai
handles these extensions also.

libtai has functions to convert calendar dates and times (such as
"March 27 1823") into TAI values and back and to input and output date
and time strings. It has functions for addition, subtraction, and
comparison of TAI times. The interfce is simple and well-documented.

If we're going to standardize on a single time format for all
platforms, I wish we could choose a good format. Unix time runs out
in 2038.

The libtai blurb is at:

http://cr.yp.to/libtai.html

I've included this below.

Public-domain source code for libtai:

http://cr.yp.to/libtai/libtai-0.60.tar.gz

The spec for TAI64:

http://cr.yp.to/libtai/tai64.html


BLURB:

libtai is a library for storing and manipulating dates and times.

libtai supports two time scales: (1) TAI64, covering a few hundred
billion years with 1-second precision; (2) TAI64NA, covering the same
period with 1-attosecond precision. Both scales are defined in terms of
TAI, the current international real time standard.

libtai provides an internal format for TAI64, struct tai, designed for
fast time manipulations. The tai_pack() and tai_unpack() routines
convert between struct tai and a portable 8-byte TAI64 storage format.
libtai provides similar internal and external formats for TAI64NA.

libtai provides struct caldate to store dates in year-month-day form. It
can convert struct caldate, under the Gregorian calendar, to a modified
Julian day number for easy date arithmetic.

libtai provides struct caltime to store calendar dates and times along
with UTC offsets. It can convert from struct tai to struct caltime in
UTC, accounting for leap seconds, for accurate date and time display. It
can also convert back from struct caltime to struct tai for user input.
Its overall UTC-to-TAI conversion speed is 100x better than the usual
UNIX mktime() implementation.

This version of libtai requires a UNIX system with gettimeofday(). It
will be easy to port to other operating systems with compilers
supporting 64-bit arithmetic.

The libtai source code is in the public domain.

Search Discussions

  • David E. Wheeler at Aug 18, 2000 at 9:04 pm

    Mark-Jason Dominus wrote:

    TAI is an international time standard. It has a number of technical
    advantages over UTC. One of these advantages is that it doesn't have
    any silly truck with leap seconds.
    ...

    Why, this sounds perfect, Mr. D! When will you write the RFC?

    David
  • Russ Allbery at Aug 18, 2000 at 9:47 pm

    Mark-Jason Dominus writes:

    TAI is an international time standard. It has a number of technical
    advantages over UTC. One of these advantages is that it doesn't have
    any silly truck with leap seconds.
    One point to be aware of with TAI, however, is that Unix system clocks
    don't normally keep TAI so you can end up with a 20-second differential or
    so due to the difference in leap seconds. Dan's libraries use an external
    table to track leap seconds and adjust. This won't matter for most
    applications (the TAI64 formats are independent of whether you're keeping
    true TAI or the bastardized Unix UTC-like TAI), but it's something to be
    aware of.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Tim Jenness at Aug 18, 2000 at 10:55 pm

    On 18 Aug 2000, Russ Allbery wrote:

    Mark-Jason Dominus <mjd@plover.com> writes:
    TAI is an international time standard. It has a number of technical
    advantages over UTC. One of these advantages is that it doesn't have
    any silly truck with leap seconds.
    libtai looks like a great idea to me.
    One point to be aware of with TAI, however, is that Unix system clocks
    don't normally keep TAI so you can end up with a 20-second differential or
    so due to the difference in leap seconds. Dan's libraries use an external
    table to track leap seconds and adjust. This won't matter for most
    applications (the TAI64 formats are independent of whether you're keeping
    true TAI or the bastardized Unix UTC-like TAI), but it's something to be
    aware of.
    I think this is a bit of a red herring. Presuambly the time on your
    computer depends on where you are synching from (if at all) - if you
    are synching to a TAI time server then you are fine. In the worst case you
    are synching to the sys admins watch so the minor actual difference
    between UTC and TAI may be irrelevant in most practical applications (our
    telescope synchronizes with the clock on the GPS satellites - a 1 second
    error in our clock means we can miss our target by 15 arcseconds (and
    that's a lot).

    --
    Tim Jenness
    JCMT software engineer/Support scientist
    http://www.jach.hawaii.edu/~timj
  • Russ Allbery at Aug 18, 2000 at 11:10 pm

    Tim Jenness writes:

    I think this is a bit of a red herring. Presuambly the time on your
    computer depends on where you are synching from (if at all) - if you are
    synching to a TAI time server then you are fine. In the worst case you
    are synching to the sys admins watch so the minor actual difference
    between UTC and TAI may be irrelevant in most practical applications
    True. It's worth bearing in mind that while there are some time sources
    that are TAI (others are UTC), xntpd keeps UTC time and only kind of deals
    with leap seconds. So most Unix systems don't have an easy source of TAI
    time.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Mark-Jason Dominus at Aug 19, 2000 at 3:47 pm
    I agree with Tim that it's a red herring that unix systems don't
    normally have access to a TAI source.

    The proposal under discussion is to use one time format for all
    platforms. So maybe there's a minor difficulty in converting unix
    time to TAI time; probably it's not as large as the difficulty in
    converting VMS time (for example) to whatever other
    platform-independent standard we were going to agree on.

    When you have one platform-independent standard, you necessarily
    accept that there are going to be conversion difficulties form the
    native time format to the standard format. Converting from unix time
    to TAI is one of the smaller such difficulties.

    We could hack Dan's library so that it carries the leap second table
    internally, and only tries to fall back to the file when the date is
    out of range of the internal table.

    I was about to start a discussion of what this would mean for calls
    like

    localtime(2000000000)

    and then I realized that, as usual, I have no idea what the RFC is
    actually proposing.


    Mark-Jason Dominus mjd@plover.com
    I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
  • Dave Storrs at Aug 21, 2000 at 4:13 pm
    If we are going to use this, I'd like to see us standardize on the
    highest-precision (i.e. attosecond) version. While it's not necessary in
    any application that I can currently think of and will probably never be
    necessary in 90% of Perl applications, when you need it, you need it, and
    if the core language doesn't support it, it can be a pain to get it.

    Well, actually...I suppose if there are huge penalties for using the
    attosecond version, maybe it wouldn't be worth it, but it doesn't sound
    from this post like that is the case.

    Dave
    On Fri, 18 Aug 2000, Mark-Jason Dominus wrote:


    TAI is an international time standard. It has a number of technical
    advantages over UTC. One of these advantages is that it doesn't have
    any silly truck with leap seconds.

    Dan Bernstein has defined a time format called TAI64 which is based on
    TAI. The format is very simple. TAI64 is almost compatible with Unix
    epoch time. TAI64 has a resolution of one second and a range of about
    300 billion years.

    Bernstein has a small, good-quality library of code for manipulating
    TAI64 values and for converting them to and from UTC or unix epoch
    time. The library is in the public domain, so there can't be any
    license or copyright objection to including it in Perl.

    TAI64 has one-second precision, but there are extensions to it,
    TAI64N and TAI64A, with nanosecond and attosecond precision. libtai
    handles these extensions also.

    libtai has functions to convert calendar dates and times (such as
    "March 27 1823") into TAI values and back and to input and output date
    and time strings. It has functions for addition, subtraction, and
    comparison of TAI times. The interfce is simple and well-documented.

    If we're going to standardize on a single time format for all
    platforms, I wish we could choose a good format. Unix time runs out
    in 2038.

    The libtai blurb is at:

    http://cr.yp.to/libtai.html

    I've included this below.

    Public-domain source code for libtai:

    http://cr.yp.to/libtai/libtai-0.60.tar.gz

    The spec for TAI64:

    http://cr.yp.to/libtai/tai64.html


    BLURB:

    libtai is a library for storing and manipulating dates and times.

    libtai supports two time scales: (1) TAI64, covering a few hundred
    billion years with 1-second precision; (2) TAI64NA, covering the same
    period with 1-attosecond precision. Both scales are defined in terms of
    TAI, the current international real time standard.

    libtai provides an internal format for TAI64, struct tai, designed for
    fast time manipulations. The tai_pack() and tai_unpack() routines
    convert between struct tai and a portable 8-byte TAI64 storage format.
    libtai provides similar internal and external formats for TAI64NA.

    libtai provides struct caldate to store dates in year-month-day form. It
    can convert struct caldate, under the Gregorian calendar, to a modified
    Julian day number for easy date arithmetic.

    libtai provides struct caltime to store calendar dates and times along
    with UTC offsets. It can convert from struct tai to struct caltime in
    UTC, accounting for leap seconds, for accurate date and time display. It
    can also convert back from struct caltime to struct tai for user input.
    Its overall UTC-to-TAI conversion speed is 100x better than the usual
    UNIX mktime() implementation.

    This version of libtai requires a UNIX system with gettimeofday(). It
    will be easy to port to other operating systems with compilers
    supporting 64-bit arithmetic.

    The libtai source code is in the public domain.
  • Russ Allbery at Aug 21, 2000 at 10:17 pm

    Dave Storrs writes:

    If we are going to use this, I'd like to see us standardize on the
    highest-precision (i.e. attosecond) version. While it's not necessary
    in any application that I can currently think of and will probably never
    be necessary in 90% of Perl applications, when you need it, you need it,
    and if the core language doesn't support it, it can be a pain to get it.
    Well, actually...I suppose if there are huge penalties for using the
    attosecond version, maybe it wouldn't be worth it, but it doesn't sound
    from this post like that is the case.
    There shouldn't be. The only potential problem with the attosecond
    version (which really isn't much of a problem) is that it will have
    varying levels of precision on different platforms, but that's generally
    true of system time anyway.

    libtai will probably need some portability munging if we go that route
    (which I like as a basic idea; djb writes pretty solid code and his
    library interface seems fundamentally sound); right now, I believe it
    fails to compile on systems without a precision timer interface, mostly
    for the TAI64NA support.

    There may be systems where we can't get anything more precise than seconds
    out of the system clock.

    --
    Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
  • Alan Burlison at Aug 23, 2000 at 10:08 am

    Mark-Jason Dominus wrote:

    If we're going to standardize on a single time format for all
    platforms, I wish we could choose a good format. Unix time runs out
    in 2038.
    Not true. On 64 bit Unix platforms time_t is 64 bit.

    Alan Burlison

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl6-language-datetime @
categoriesperl
postedAug 18, '00 at 8:52p
activeAug 23, '00 at 10:08a
posts9
users6
websiteperl6.org

People

Translate

site design / logo © 2021 Grokbase