Re: [LEAPSECS] Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

From: Markus Kuhn <Markus.Kuhn_at_CL.CAM.AC.UK>
Date: Fri, 05 Aug 2005 13:12:26 +0100

Mark Calabretta wrote on 2005-08-05 07:53 UTC:
> You are saying that POSIX time, unix system time, is UTC, right?
> supports that but apparently
> POSIX time keeping is a bit of a shambles - check Steve Allen's web page
> or the man page for
> time(2). (It also begs the question - why does unix maintain a table of
> leap seconds?)

POSIX timekeeping is not really "in shambles". The current phrasing of
the standard was selected after long and careful deliberations on the
difference between TAI and UTC. It reads:

 "4.14 Seconds Since the Epoch

  A value that approximates the number of seconds that have elapsed since
  the Epoch. A Coordinated Universal Time name (specified in terms of
  seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January
  1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is
  related to a time represented as seconds since the Epoch, according to
  the expression below.

  If the year is <1970 or the value is negative, the relationship is undefined.
  If the year is >=1970 and the value is non-negative, the value is related
  to a Coordinated Universal Time name according to the C-language expression,
  where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:

    tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
      (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
      ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

  The relationship between the actual time of day and the current value
  for seconds since the Epoch is unspecified.

  How any changes to the value of seconds since the Epoch are made to
  align to a desired relationship with the current actual time is
  implementation-defined. As represented in seconds since the Epoch, each
  and every day shall be accounted for by exactly 86400 seconds.


    The last three terms of the expression add in a day for each year
    that follows a leap year starting with the first leap year since the
    Epoch. The first term adds a day every 4 years starting in 1973, the
    second subtracts a day back out every 100 years starting in 2001, and
    the third adds a day back in every 400 years starting in 2001. The
    divisions in the formula are integer divisions; that is, the remainder
    is discarded leaving only the integer quotient."

So POSIX says in other words:

  - The term "Seconds since the epoch" (which is elsewhere used to define
    the meaning of the time_t type used in various API calls) is defined
    to represent an integer encoding of a YYYY-MM-DD hh:mm:ss display
    of a clock display that approximates UTC.

  - It leaves the question of how accurate this approximation of UTC has to be
    in relation to "true UTC" up to the implementation (sensible, because
    no every implementation has good knowledge of UTC; not everyone uses or
    cares about NTP, GPS, etc.).

  - It leaves the question of what to do near a leap second up to
    the implementation (sensible, because not every implementation has
    good knowledge of UTC or of upcoming leap seconds). It leaves space
    for other specifications (such as UTS) to fill that gap, by defining
    the exact behaviour of an implementation that knows about highg-accuracy
    UTC and forthcoming leap seconds.

In other words, POSIX does not require you to hook up your computer to a
GPS receiver, if you don't want to.

More on UTS:


Markus Kuhn, Computer Laboratory, University of Cambridge || CB3 0FD, Great Britain
Received on Fri Aug 05 2005 - 05:12:40 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT