[LEAPSECS] Future time

[Stephen Colebourne]

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.

Stephen