Re: date(1) doesn't handle leap-seconds?

[Alan Barrett <apb%cequrux.com@localhost>]

On Sun, 02 Nov 2008, Paul Goyette wrote:
> Ah, OK.  So POSIX syystems are all currently off by 23 seconds, and soon  
> to be off by 24 seconds (there's another leapsecond coming up at the end  
> of 2008).  Bummer.

Well, the time as struct tm as returned by localtime(3) or gmtime(3)
will be correct, though you could say that the time as time_t (or struct
timeval or similar related types) is incorrect.  However, see the REDO
variable in src/share/zoneinfo/Makefile for some support for dealing
with time in the "correct" non-posix way.  Unfortunately, I don't see
any support for this in ntpd(8).  Also, other systems that you interact
with by sending timestamps as large integer values (such as in tarballs,
file system dumps, the rsync protocol) will be confused if you don't
use the posix interpretation.  (See time2posix(3) and posix2time(3)
for conversion functions, which unfortunately are not used by most
applications that should use them.)

Of course, if you count seconds "correctly", then it's impossible to
have perfectly accurate conversions between struct tm and time_t for
times so far in the future that the number of intervening leap seconds
is unknown.  (Future leap seconds are usually announced a few months
in advance.)  However, you can convert correctly between time_t and
struct tm for all times in the past, and for times in the sufficiently
near future that the number of leap seconds is known.  POSIX didn't
ask me, but I would have recommended that time_t should count seconds
"correctly" without ignoring leap seconds, and that applications or
protocols that need to accurately represent future dates should use a
representation with explicit year/month/day/etc components instead of
time_t.

--apb (Alan Barrett)