On Sun 2012/01/22 19:04:05 -0000, "Poul-Henning Kamp" wrote in a message to: Keith Winstein <[email protected]> and copied to: Leap Second Discussion List <[email protected]>
>> Plenty of applications need to record dates >>more than six months in the future; > >They can trivially do that, but they have to do it in a format >that can represent the time. > >"struct tm" can do that, (if we add frational seconds to it as >I proposed) I agree. It is the only way that a future UTC or localtime can be stored. >But time_t and realtime_t can not, because they are scalar and >the scalar number of seconds between any epoch and UTC timestamp >more than 6 months out in the future, is undefined. At the current rate of leap second insertion, the worst-case scenario is that an as-yet unannounced leap second will occur in (slightly over) 6 months. 1 second in 6 months is one part in 16,000,000 which, for most (all?) civil timekeeping purposes, is well enough defined to compute a time interval of sufficient accuracy. In any case, as Keith implied, often only the intended order of future events is important. So effectively what is needed is a function to subtract two tm structs. Currently this is done by the user by converting the two structs to time_t and subtracting those. The implicit assumption is that that would now be done via realtime_t. However, that need not be so. All that is required is for users to be provided with a convenient way to subtract two tm structs. Regards, Mark _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
