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