An interesting long-term exercise: extend (once again) the zic-produced POSIX-like time zone string format to cover Troll. (Have the in-place extensions been proposed to the POSIX governing body for its standard?) @dashdashado
Arthur David Olson wrote:
An interesting long-term exercise: extend (once again) the zic-produced POSIX-like time zone string format to cover Troll.
It could be done. Troll has only 8 people, though (during winter). Maybe we should wait for a few years, to make sure they really need to change their clocks four times a year, as I'd hate to force dozens of programmers to rewrite many thousands of lines of code merely to add a feature that isn't really needed. (I don't mind the part about updating billions of computers, as we've mostly automated that.) I have the sneaking suspicion that Troll's next boss might change the Troll rules, rendering the feature unnecessary. One can only hope. If we do extend POSIX, we should also support William Willett's original daylight-saving-time proposal back in 1907, which would have changed the clocks eight times a year! It was never put into practice, but one never knows what those crazy Antarctic scientists will do next. See <http://www.webexhibits.org/daylightsaving/willett.html>.
(Have the in-place extensions been proposed to the POSIX governing body for its standard?)
Sorry, I haven't gotten around to that yet. I would like to do it at some point.
Arthur David Olson wrote:
An interesting long-term exercise: extend (once again) the zic-produced POSIX-like time zone string format to cover Troll.
Not really an appealing proposition. The 400-year hack is serviceable. But if you want to go this route, I suggest abandoning the concept of a single DST offset and initialism in favour of attaching them to each transition rule. Say, for Troll, UTC0,J60/1=CET-1,M3.5.0=CEST-2,M10.5.0/3=CET-1,J311 Rules: if there are more than two transitions per annum, the DST offset and initialism must be omitted from the base part of the TZ spec. There may be any number of transition rules. A rule may have appended "=", initialism, and offset: the initialism and offset (from UT) have the same syntax as in the base part. A rule with no "=" describes a return to the standard offset and initialism (from the base part), unless it's the first of the exactly two rules in an existing-format spec that specifies a DST initialism in the base part. The zone is reckoned to be "on DST" iff the current offset differs from the standard offset specified in the base part. As a bonus, this could express a permanently-on-DST zone, by using a fake transition to DST and no transition back: CET-1,J1=CEST-2 Possible refinement: allow the isdst flag to be explicitly stated with each initialism/offset pair. That would allow a permanently-DST arrangement to be specified more directly, but more importantly would allow for Troll on CET to be reckoned not-DST. Currently zic itself determines isdst based on matching the standard offset, and would need an addition to take an explicit flag in its input (presumably in the SAVE column). -zefram
Date: Tue, 25 Mar 2014 15:15:58 +0000 From: Zefram <zefram@fysh.org> Message-ID: <20140325151558.GF18071@fysh.org> | As a bonus, this could express a permanently-on-DST zone, There is no such thing - what you're describing is just a zone where the time base does not (all that closely) match solar time. We have lots of those already. The (totally meaningless) timezone abbreviation can, of course, be anything that makes sense (so if it wants to have an "S" for "summer" for times that apply in the middle of winter, then by all means...) While extensions to the posix string as useless as it is) are being contemplated, more important would be to make sure that it can express an arbitrary number of changes to the base offset (and if you care about it, the abbreviation) - with that, if necessary, strange summer time representations can be faked as zone offset changes if the normal mechanism cannot cope. Of course, doing this must necessarily lead to very long (possible) env strings - probably too long (possibly) to actually store literally. Just maybe, someone might suggest that perhaps the actual timezone data might be better in a file, with the env containing the file name! kre
participants (4)
-
Arthur David Olson -
Paul Eggert -
Robert Elz -
Zefram