On Sat, Jan 21, 2012 at 7:09 PM, Poul-Henning Kamp <p...@phk.freebsd.dk> wrote: > In message > <camzhqmm18e8ssh3prt+jz3_hvrapiewyxt4yti47lfcujxn...@mail.gmail.com> > , Keith Winstein writes: > >>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.). > > Correct, if we don't have the knowledge to do it, we fail the conversion.
>>Isn't this a problem? > > If it is, it's a not problem with the API, but with the way > leap-seconds are defined. Hmm, in practice I think the plan to simply fail with an error is going to be a non-starter. Plenty of applications need to record dates more than six months in the future; e.g. in a calendar program, the user will want to schedule a meeting for August 1, 2012, from 9 a.m. EDT to 10 a.m. EDT. The program will want to do all the normal things -- calculate the duration of the meeting, how far in the future it is (so it can put it in sorted order along with the other events of that day), etc. In a subscription service, we might want to say that the user's subscription lasts until January 22, 2013 at 12:21 p.m. (one year hence) and give them a countdown (264 days remaining) as that timestamp approaches. Perhaps you envision a whole other, separate API for representing and validating EDT (and other civil time, and UTC) timestamps and doing approximate arithmetic on them until the happy moment when they can finally be successfully converted into a realtime_t, but if so this introduces considerable extra complexity and will need to be specified. People are going to want to evaluate the whole package of what they're getting into before they sign on to this thing. The notion that "the API" can do nothing more than report an error message is not quite right. There are some alternatives: 1) Ignore leap seconds when converting future EST/EDT/UTC-specified moments into a timestamp. ==> This is the current POSIX status quo, and it works pretty well for the vast majority of applications. 2) Correctly account for past leap seconds, and ignore yet-to-be-disseminated future leap seconds when converting EST/EDT/UTC-specified moments into a timestamp. ==> This is the current status quo using the "right" timezone files. 3) Correctly account for past leap seconds, and bomb out with an error when converting future EST/EDT/UTC-specified moments. ==> This is your proposal. 4) In addition to the "double *error" returned by tai_time(), also report an error estimate from the conversion routines realtime_tm() and tm_realtime(), reflecting the uncertainty from the fact that future leap seconds may not be known far enough in advance. The conversion to and from UTC is uncertain, but not totally unknowable. Calendar applications might be perfectly happy with a +/- 10 second error on a timestamp years in the future. 5) Instead of a quantitative estimate from #4, you could simply return a boolean reflecting whether the conversion is exact or might be some seconds off because of as-yet-unannounced leap seconds. That is, instead of "bomb out and return an error" for future timestamps, the API can "do the best conversion possible and return a warning if necessary." === On balance, I think #5 may be the best compromise between usability and correctness. And it is much more likely to be accepted than an API that rigidly bombs out for timestamps in the future, just because the conversion may be off by 1 second. Most applications do not need this level of accuracy for future timestamps but still want a conversion. -Keith _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs