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). 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 _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
