Date: Mon, 27 Feb 2012 15:50:00 +0200 From: Alan Barrett <apb@cequrux.com> Message-ID: <20120227135000.GW1788@apb-laptoy.apb.alt.za> | I always considered "is DST in effect, and if so, what is the | offset from standard time" to be an important question, Could you perhaps explain why? The important questions to me seems to be to be able to determine the relative offsets of clocks in different parts of the world at a particular instant (with one of them usually being a UTC clock, but that's not important), and to be able to measure time intervals at some location, taking into account clock discontinuities. Notions of "standard" time vs summer time are purely ones of perception. For those areas with bi-annual clock jumps, we could just as easily consider the time during summer to be the "standard" time, and that that applies during winter to be "winter adjustment time" applied to allow the sun to rise at an earlier clock time in winter. It is all just a matter of perception, and I don't really think it important at all. The only real notion of "standard" time that we could adopt, that would be meaningful, would be to revert strictly to a set of 24 (or 48, or 96) zones determined by longitude. Of course, for about half the world that would make that definition of "standard" time different from the one observed in practice, and politically and socially, it would be totally ignored, so there's probably little real incentive to bother. We need the tm_isdst field for API compatability, and because it allows mktime() to be instructed which of two possible results is desired in the case of ambiguous input. If it weren't for those, I'd happily see it simply go away, as I don't think the information it conveys is useful. All that said, I'm happy to make the rules for America/Creston be whatever the community feel they should be. I'm not going to delay this update to wait for this to be perfected however. We're talking about data that affects timestamps that are almost 70 years old. Since until this update appears, Creston hasn't had a zone file entry that was correct for it at all, I think they (and we) can manage to wait another update or two to make corrections, if we can't come to a conclusion on this in the next couple of days. Do note that the updated proposed update I sent out just a short while ago was prepared before I saw any of the recent few messages, even though it is dated after them (I was preparing it, not reading incoming mail...) That is, it was not intended to represent any kind of conclusion on this issue. kre