[LEAPSECS] Lets get REAL about time.

[Steve Allen]

On 2012 Jan 21, at 14:34, Zefram wrote:

> This is a reason for having a distinct representation of UTC timestamps.

> You can have a future UTC time, and convert it between UTC and (say)

> London time, without being able to represent it as a realtime_t.  I guess

> you need a conversion interface that accepts *two* tz parameters (source

> and destination).


Someone should correct me if I'm wrong, but it is my impression
that the TC TIMEZONE folks (who are largely a continuation of the
folks who fixed up the iCalendar standard for its new family of
RFCs) are dealing with exactly this sort of thing.

Note that the problem of assigning a timestamp to a future event
is problematic simply because of bureaucrats changing the rules
for timezone events, and in that sense the TAI value for a future
event expressed in local time may not be predictable less than
a week in the future, at least based on the experience of the
folks who maintain the tz database.
                                                                                
--
Steve Allen               <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory      Natural Sciences II, Room 165  Lat  +36.99855
University of California  Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064      http://www.ucolick.org/~sla/   Hgt +250 m