[LEAPSECS] Lets get REAL about time.

[Keith Winstein]

On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:


> libc will need an updated table of leap-seconds to give you UTC,

> and if you hand it a timestamp that is more than some set delta-T

> from the last entry in the leapsecond table, it will return E2BIG

> rather than give you a potentially wrong timestamp.


My concern is with this part of the proposal.

You are saying that if the time given is more than six months in the
future, realtime_tm() will simply return an error and will not be able
to produce a human-readable timestamp (whether in UTC, EST, EDT, CET,
BST, etc.).

Isn't this a problem? Plenty of applications try to display dates and
times (both in the local time zone and in UTC) that are more than six
months in the future. E.g. calendar programs, the at tool, astronomy
programs, billing software, accounting software, Web browsers (e.g.
showing cookie expirations in human-readable form).

Not all of these programs _display_ future timestamps to a resolution
of 1 second (or 2^-112 second in your case), but many of them will
want to do the conversion and then truncate the display precision.
That conversion becomes impossible here.

Imagine if we implemented localtime(), gmtime() and ctime() functions
on top of this API -- I'm guessing many programs would fail, because
they often try to localtime() a time_t that is months in the future.

How would you handle this?

-Keith