[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

# Re: UTC, GMT, leap seconds

```joost witteveen <joostje@cistron.nl> writes:
>Some time ago, I though I understood things UTC/GMT and leap seconds.
>But my date(1) doesn't confirm what I thought.
>
>I would assume that `the number of seconds since 00:00:00, Jan 1, 1970'
>doesn't include leap seconds, whereas Mid European Time does.
>
>But if I do
>
>\$ TZ=MET date; date +"%s"
>Fri Jul 23 23:06:16 MEST 1999
>932763976
>
>both refer to excactly the same time (without leap seconds).
>
>Does anyone know if this is OK? And, is my memory correct in
>telling me that UTC also should be without taking leap seconds
>into account? (I thought that was the difference in between GMT and UTC).

As I understand it:

UTC does account for leap seconds.

POSIX mandates that system time calculations do not account for leap
seconds.  That is, time() for one minute before midnight will always
return 120 seconds less than time() for one minute after midnight.

Effectively, Unix system time is defined as the number of seconds
since T, where T is shortly after midnight on Dec 31 1969.  T shifts
by one second every time we have a leap second.

I think this is unfortunate.  It means we cannot calculate the exact
time between two events by subtracting two values returned by time().
(I believe this is permitted by POSIX.  However, according to the ANSI
C standard, you are supposed to use difftime() instead.  I believe it
also disregards leap seconds.)

The rationale for the POSIX choice is that we need to be able to
repeat a calculation and get exactly the same result.  If I calculate
the number of seconds over some time span in the future, that
calculation cannot account for leap seconds.  (They occur at
irregular, unpredictable intervals, as determined by the slowing of
the earth's rotation and committee decisions.)  Rather than doing a
calculation that was only probably correct, they chose to disregard
leap seconds.

- Jim Van Zandt

```