On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote: > On 19 January 2014 15:34, Daniel R. Tobias <[email protected]> wrote: >> On 18 Jan 2014 at 19:51, Warner Losh wrote: >> >>> Of course, the 6 month window does make it impossible to compute a time_t >>> for a known >>> interval into the future that's longer than 6 months away... >> >> What are the applications that actually need to schedule events more >> than 6 months in the future that need to be precisely synchronized to >> civil time at a resolution of under a second? Gee, I might miss the >> plane for the airline reservation I made 7 months in advance if I >> show up one second late! (Actually, both myself and the airline, if >> we care about this level of detail, will have adjusted our >> clocks/watches by flight day, including any leap seconds in the >> interim, and I'll be right on time.) > > If you want to store a time in the future its best to focus on the > local time. In API terms, a UTC class is best representing data using > two numbers, typically modified-julian-day + second-of-day. Stored > like that, the announcement of a leap second doesn't generally affect > things. ie. Separation of the concept of day/date from time-of-day is > a Good Thing for most users. > > When such concepts were in Java's JSR-310, I concluded that you needed > to have both TAI and UTC to provide full user control. TAI so a user > could schedule something n SI seconds in the future and UTC to > schedule something more sensibly. Eventually we concluded that most > users just don't care/know enough about TAI/UTC/leaps, so we removed > them.
You had me all the way until the last sentence... s/removed/hid for power users/ would have been much better outcome. But I do understand that it seems to be part of the prevailing attitudes today... Warner _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
