Date: Wed, 22 May 2013 16:14:40 -0400 From: random832@fastmail.us Message-ID: <1369253680.19347.140661234432069.5815BFD1@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@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@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@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