[tz] On merging timezones - a radical proposal.

[Robert Elz]

    Date:        Wed, 22 May 2013 16:14:40 -0400
    From:        random832 at fastmail.us
    Message-ID:  <1369253680.19347.140661234432069.5815BFD1 at webmail.messagingengine.com>

  | Why is that not what localtime() means?

It means the the time according to wherever you have defined the system's
current locality to be.   The interface has no direct way to know what
other zones might have been a better fit for some particular file, or
timestamp, all it is given is a single timestamp with no additional data
(except what has been set as the timezone).

This isn't our API, it way predates the tz project, all we do is make the
interface that had been defined work properly, everywhere, rather than
just in the US (using 1970's vintage summer time rules) which is what
came before (or the various attempts using specifications encoded in
evnrionment variables that have gradually gotten closer to rational, but
also are now so complex as to be almost incomprensible - and still get it
wrong).

If more than current locality local time is needed, the application needs
to alter the timezone before calling localtime.  If it does that, the
timezone data works fine.

You seem to be advocating a system where all timestamps are created (and 
retained) in local time, rather than UTC - so that if I create a file at
15:00, move to a different timezone, and look at the file it will still
say 15:00, regardless of their being another file that I more recently
created claiming (correctly) to be 14:00 on the same day (becase I moved
west very quickly, or more likely, east across the date line).

There are systems that do that, and they're truly disgusting...   The
slight weirdness of having a file which I created at 15:00 later show up
as having been made at 10:00 in my new local frame of reference is easy
to come to grips with.  I did make it at 10:00 (where I now am).

In an easelier message, random832 at fastmail.us quoted Guy Harris:
|  > so I view it as making an implicit promise that localtime() can convert
|  > any value of "seconds since the Epoch" to local time

and then said:
| Those go back to 1907, and that's on 32-bit systems. 

No, the Epoch is 1970 (1970-01-01 00:00:00 UTC).  Times before that,
when they can be represented (when time_t is signed, which is common, but
I think not guaranteed) are before the Epoch, not since it.

But (again personally) I'd like to gradually push the tzdata reference point
backwards, there are systems that can represent times before the epoch, and
it would be good to be able to correctly convert those as well- at least
back to about the beginnings of standardised time (or the earliest that can
be represented on the system if that is later than the beginning of
standardiesd time).

It isn't urgent that we do that (to put it very mildly) and we do include
data before the epoch when somenle locates a source to tell us what it should
be - eventually when that should lead to more zone splits, I'd like to see
those happen.

Attempting to make things easier for users by introucing subtle bugs in
their systems isn't really a sensible desire - especially as what we're
talking about is something that most people do once - and if they ever do
need to repeat it, subsequesnt configs are typically very easy as the user
knows what is going on and how the interface works - it is only the first
time where this stuff ever looks complicated.


random832 at fastmail.us said:
| We already don't handle (to make up an arbitrary example) people who moved
| from New York to Phoenix in 1992, but spent a month-long vacation in Florida
| in 2004. 

We don't provide the data, as we have no idea what that data should be,
and there wouldn't be enough consumers for it in any case to make it
worthwhile distributing.

But tzdata certainly can handle it, if you want to, you can easily make a
new private zone file with whatever jumps of local clock time that
represent your own idea of reality.

Once that's done, everything will use it just fine, just the same as
any other zone.

If you don't like the syntax of the zone files, you could easily write
an application with a nice GUI interface that would allow users to
create a zone (in zic input format - output of the application - or even
in binary zone file format directly) that would make it as easy for
the users as you want it to be.   By all means, go ahead, but don't
expect it to become a part of this project (a link to it from the web
page would probably happen, but that's it.)

random832 at fastmail.us said:
| Since you can't define zones in terms of other zones, we don't even make it
| easy for them to handle themselves.

You could also write an application (probably even just a script) that would
do it that way as well - extracting parts of other zones and combining
them together to make a new zone specification.   Again, feel free.

kre