Oddness in file interpretation - I assume I am missing something...
The current files have the following zone & rules: Freetown Zone Africa/Freetown -0:53:00 - LMT 1882 -0:53:00 - FMT 1913 Jun # Freetown Mean Time -1:00 SL %s 1957 0:00 SL %s Rule SL 1935 1942 - Oct 1 0:00 0 WAT Rule SL 1957 1962 - Jun 1 0:00 1:00 SLST Rule SL 1957 1962 - Sep 1 0:00 0 GMT And zic produces, among others, the following transition: Africa/Freetown Sun Jun 1 00:52:59 1913 UTC = Sat May 31 23:59:59 1913 FMT isdst=0 Africa/Freetown Sun Jun 1 00:53:00 1913 UTC = Sat May 31 23:53:00 1913 WAT isdst=0 The problem/question I have is: based on the above rules, it is not at all clear to me that Sat May 31 23:53:00 1913 should be designated 'WAT'; in fact I would have thought there would be a case for it being 'FMT' since none if the 'SL' rules apply in 1913. This is further complicated by the following rules & zones: Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time 0:00 Algeria WE%sT 1940 Feb 25 2:00 1:00 Algeria CE%sT 1946 Oct 7 Rule Algeria 1916 only - Jun 14 23:00s 1:00 S Rule Algeria 1916 1919 - Oct Sun>=1 23:00s 0 - which for the transition in 1911 produces 'WET'; apparently *not* using the 'S' from the first rule. And this set: Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana %s Rule Ghana 1936 1942 - Sep 1 0:00 0:20 GHST Rule Ghana 1936 1942 - Dec 31 0:00 0 GMT which produces 'GMT' for the transition in 1918. Can someone confirm that zic is doing the right thing (which I kind of assume it is by definition), and perhaps give me a rule to follow when performing the %s substitutions? Any help would be greatly appreciated.
Philip Warner <pjw@rhyme.com.au> writes:
Can someone confirm that zic is doing the right thing (which I kind of assume it is by definition), and perhaps give me a rule to follow when performing the %s substitutions?
It's doing what I wanted, anyway. Abbreviations like "FMT" refer to a mean time for a particular location (e.g., GMT for Greenwich, PMT for Paris). So the database has Sierra Leone observing Freetown Mean Time (53 minutes west of GMT) until West Africa Time was introduced in 1913. I think the general rule is that, before the first transition, you use the first standard-time abbreviation (not the first abbreviation, the first standard-time abbreviation). If the zic documentation doesn't say this clearly enough for you, perhaps you could propose a patch? That would help others grok it.
Paul Eggert wrote:
Can someone confirm that zic is doing the right thing (which I kind of assume it is by definition), and perhaps give me a rule to follow when performing the %s substitutions?
It's doing what I wanted, anyway. Yep; zic is almost by definition 'right', just trying to understand it.
I think the general rule is that, before the first transition, you use the first standard-time abbreviation (not the first abbreviation, the first standard-time abbreviation).
If the zic documentation doesn't say this clearly enough for you, perhaps you could propose a patch? That would help others grok it.
Will do when I have it sorted out completely; but your answer was very helpful. Looking more closely at zic, it *seems* that the rule is: - expand all rules (one per year) - Use the prior rule text if there is one - if no prior rule text, use the latest rule text that has MAX in its 'to' field, zero offset, and which falls inside the range of dates of the zone line - if no such rule exists, use the first rule with 0 offset which is also in the range of dates allowed by the zone line Now my parser produces the same output as zdump, except for riyad87/88/89. which I am fixing; once that is done, I will send some patches. In terms of patches; should I send a patch for the man page? Or for the C file (or both, if I have time)?
participants (2)
-
Paul Eggert -
Philip Warner