kre at munnari.OZ.AU
Mon Feb 27 14:52:33 UTC 2012
Date: Mon, 27 Feb 2012 15:50:00 +0200
From: Alan Barrett <apb at cequrux.com>
Message-ID: <20120227135000.GW1788 at 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.
More information about the tz