On Jan 21, 2012, at 4:20 PM, Keith Winstein wrote: > On Sat, Jan 21, 2012 at 7:44 AM, Poul-Henning Kamp <[email protected]> > 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).
We need some kind of 'late binding' so that we can have time that's in July 2012 when called from an app in Dec 2011 that shifts 1s once the leap tables are updated... Warner _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
