[LEAPSECS] Future time

[Warner Losh]

On Jan 19, 2014, at 11:21 AM, Stephen Colebourne wrote:


> On 19 January 2014 15:34, Daniel R. Tobias <dan at tobias.name> 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