The rule for Macau ends in 1980 but its Zone indicates that the rules end in 1999. What is the correct rule for Macau from 1980 through 1999? Did they return to LMT? Rule Macau 1975 1977 - Apr Sun>=15 3:30 1:00 S Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 PRC C%sT
From 1912 to 1999 Dec 20 Macau was on Macau time, with a UT offset of +8:00 hr From '78-'80 from Apr to Oct they also used a summertime offset of 1hr. On 2011-02-22 06:14, jrl wrote:
The rule for Macau ends in 1980 but its Zone indicates that the rules end in 1999.
What is the correct rule for Macau from 1980 through 1999? Did they return to LMT?
Rule Macau 1975 1977 - Apr Sun>=15 3:30 1:00 S Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 8:00 Macau MO%sT 1999 Dec 20 # return to China 8:00 PRC C%sT
Date: Tue, 22 Feb 2011 11:14:18 +0000 From: jrl <jrl@terraatlas.com> Message-ID: <E468A544C5BEF74DBF22CAAB3FD50DE810F47BBB@UNIVERZ.terraatlas.local> | What is the correct rule for Macau from 1980 through 1999? | Did they return to LMT? I wonder if there is any way we can make the documentation clearer that the rules do not specify intervals, but transition points. People keep asking questions (like this one) that make no sense at all if the rules are interpreted correctly, but would be perfectly legitimate if the rules were doing something like "specifying the period when summer time applies". Since this mistake is so commonly made, it must be a problem with the tz documentation. Unfortunately, I can't see it (which is often true when someone who knows the answer tries to see why others cannot see it). Does anyone have any ideas how we can make this clearer? Is the problem that people are just reading the data files, and ignoring the documentation? Do we need to add some explanatory comments in every data file? kre ps: the Macau rules say that the last time there was a std/summer time transition in Macau was the 3rd SUn in October, 1980, since then the only change has been the change of time zone abbreviation when Macau became part of China again. So, no, it dod not revert to LMT, there simply were no more transitions - and once you understand that the rules are used to specify transition points, this is really all very obvious.
I don't think I made myself clear... According to the documentation, the Rule says that the time change ran ends on the Sunday before the 15th for the years 1978, 1979, and 1980. The documentation should indicate what you say is true: Rule Macau 1978 1980 - Oct Sun>=15 0:00 0 - I read the line above as follows: In October 1980, the rule changed to standard time. So at this point, refer to the Zone. The Zone says: 8:00 Macau MO%sT 1999 Dec 20 # return to China Meaning use the Macau rules until Dec 20, 1999 There are no Macau Rules after October of 1980. SO... in my mind it means we revert to the overall rule of the Zone for that period. The Zone says it is in effect from 1912 through 1999 - use Macau rules. If there are no rules, then revert back to the rule of the Zone. That makes you correct in that the Zone is 8:00 offset from GMT not 7:34:20 LMT. What doesn't make sense if why a set of Rules is used that ends prior to the end of the period used by the zone. It's a moot point but it confuses the flow. Perhaps a "max" in place of the 1980 would make this more clear. It would not interrupt the flow because the Zone says ignore Macau after 1999. The max is used elsewhere. Why is it NOT used here? ________________________________________ From: kre@munnari.OZ.AU [kre@munnari.OZ.AU] Sent: Tuesday, February 22, 2011 8:00 AM To: tz@lecserver.nci.nih.gov Subject: Re: Macau Date: Tue, 22 Feb 2011 11:14:18 +0000 From: jrl <jrl@terraatlas.com> Message-ID: <E468A544C5BEF74DBF22CAAB3FD50DE810F47BBB@UNIVERZ.terraatlas.local> | What is the correct rule for Macau from 1980 through 1999? | Did they return to LMT? I wonder if there is any way we can make the documentation clearer that the rules do not specify intervals, but transition points. People keep asking questions (like this one) that make no sense at all if the rules are interpreted correctly, but would be perfectly legitimate if the rules were doing something like "specifying the period when summer time applies". Since this mistake is so commonly made, it must be a problem with the tz documentation. Unfortunately, I can't see it (which is often true when someone who knows the answer tries to see why others cannot see it). Does anyone have any ideas how we can make this clearer? Is the problem that people are just reading the data files, and ignoring the documentation? Do we need to add some explanatory comments in every data file? kre ps: the Macau rules say that the last time there was a std/summer time transition in Macau was the 3rd SUn in October, 1980, since then the only change has been the change of time zone abbreviation when Macau became part of China again. So, no, it dod not revert to LMT, there simply were no more transitions - and once you understand that the rules are used to specify transition points, this is really all very obvious.
When I originally wrote our compiler for this file format, I also had troubles understanding it. I think the item which I found most confusing was the choice of words for 'RULE' and 'ZONE'. In my mind now ZONE is in more than anything else 'an offset and set of D/S rules' to apply, whereas RULE is more than anything else 'a transition point for D/S within that set of rules' On 2011-02-22 08:00, Robert Elz wrote:
Date: Tue, 22 Feb 2011 11:14:18 +0000 From: jrl<jrl@terraatlas.com> Message-ID:<E468A544C5BEF74DBF22CAAB3FD50DE810F47BBB@UNIVERZ.terraatlas.local> | What is the correct rule for Macau from 1980 through 1999? | Did they return to LMT?
I wonder if there is any way we can make the documentation clearer that the rules do not specify intervals, but transition points.
People keep asking questions (like this one) that make no sense at all if the rules are interpreted correctly, but would be perfectly legitimate if the rules were doing something like "specifying the period when summer time applies".
Since this mistake is so commonly made, it must be a problem with the tz documentation. Unfortunately, I can't see it (which is often true when someone who knows the answer tries to see why others cannot see it).
Does anyone have any ideas how we can make this clearer? Is the problem that people are just reading the data files, and ignoring the documentation? Do we need to add some explanatory comments in every data file?
kre
ps: the Macau rules say that the last time there was a std/summer time transition in Macau was the 3rd SUn in October, 1980, since then the only change has been the change of time zone abbreviation when Macau became part of China again. So, no, it dod not revert to LMT, there simply were no more transitions - and once you understand that the rules are used to specify transition points, this is really all very obvious.
Date: Tue, 22 Feb 2011 13:19:26 +0000 From: jrl <jrl@terraatlas.com> Message-ID: <E468A544C5BEF74DBF22CAAB3FD50DE810F48C13@UNIVERZ.terraatlas.local> | Meaning use the Macau rules until Dec 20, 1999 | There are no Macau Rules after October of 1980. Yes. | SO... in my mind it means we revert to the overall rule of the Zone No, no rules means no transitions, the time just continues forward (like the clock on your wall) without any strange jumps. Whenever the time jumps, we need a transition point, the rules say when those transition points appear. | If there are no rules, then revert back to the rule of the Zone. Where do you think the documentation says that? Because if there is somewhere, we need to fix it, because that's not how it works at all. The rules give the method for finding the transition points, when there is no transition point, time just moves forward, as time always has. | What doesn't make sense if why a set of Rules is used that ends prior | to the end of the period used by the zone. Because there was a period when there were transitions, and that period ended, the rules cover the period of transitions. | Perhaps a "max" in place of the 1980 would make this more clear. No, just the opposite. We use "max" when we have transitions that are continuing into the future, to some (as yet) undetermined future time. When we know when the transitions stopped occurring, we say so, that is what makes things clear. Once again, the point of the rules is to provide a method by which we calculate the points at which local wallclock time experiences a non-continuity, and that's it. Nothing else is reasonably possible, as these things are not necessarily nice nested "go forward and back" operations that could be expressed using other means. kre ps: you said "the time change ran ends on the Sunday before the 15th for the years 1978, 1979, and 1980" whereas the rule you quoted in the earlier mail was "the first sunday on or after the 15th" (Sun>=15) (a way of saying "the third sunday") - I assume the "before" in your message was just a typo/thinko.
Robert, All this said Robert, your clarification is helpful, and I thank you for that. Architecturally, my picture of a Zone (transition), as an individual element/object/entity for any given period of time will have a fixed beginning and ending. The end is when the new transition starts or for lack of one, it ends here and now.
From that point of view, "max" is appropriate because for that entity (one with a fixed beginning and ending), the process of determining the transition via a given date, will discard the old object for the new one, making the previous "max" valid but for a transition that is no longer valid.
Consider the picture as it would look in 1999, before the PRC transition, [for Macau]. --- as of Nov 1999 --- Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 max - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912 The word "max" would be entirely appropriate. By your current listing, when PRC became relevant, it was then necessary to remove the "max" and put in something else... say 1980. I would argue to leave it as it would have been at that time. The addition of the new transition would negate the effect of the "max" and there would be no need for a change at that time. Regards, Jamie -----Original Message----- From: kre@munnari.OZ.AU [mailto:kre@munnari.OZ.AU] Sent: Tuesday, February 22, 2011 10:44 AM To: tz@lecserver.nci.nih.gov Subject: Re: Macau Date: Tue, 22 Feb 2011 13:19:26 +0000 From: jrl <jrl@terraatlas.com> Message-ID: <E468A544C5BEF74DBF22CAAB3FD50DE810F48C13@UNIVERZ.terraatlas.local> | Meaning use the Macau rules until Dec 20, 1999 | There are no Macau Rules after October of 1980. Yes. | SO... in my mind it means we revert to the overall rule of the Zone No, no rules means no transitions, the time just continues forward (like the clock on your wall) without any strange jumps. Whenever the time jumps, we need a transition point, the rules say when those transition points appear. | If there are no rules, then revert back to the rule of the Zone. Where do you think the documentation says that? Because if there is somewhere, we need to fix it, because that's not how it works at all. The rules give the method for finding the transition points, when there is no transition point, time just moves forward, as time always has. | What doesn't make sense if why a set of Rules is used that ends prior | to the end of the period used by the zone. Because there was a period when there were transitions, and that period ended, the rules cover the period of transitions. | Perhaps a "max" in place of the 1980 would make this more clear. No, just the opposite. We use "max" when we have transitions that are continuing into the future, to some (as yet) undetermined future time. When we know when the transitions stopped occurring, we say so, that is what makes things clear. Once again, the point of the rules is to provide a method by which we calculate the points at which local wallclock time experiences a non-continuity, and that's it. Nothing else is reasonably possible, as these things are not necessarily nice nested "go forward and back" operations that could be expressed using other means. kre ps: you said "the time change ran ends on the Sunday before the 15th for the years 1978, 1979, and 1980" whereas the rule you quoted in the earlier mail was "the first sunday on or after the 15th" (Sun>=15) (a way of saying "the third sunday") - I assume the "before" in your message was just a typo/thinko.
On 22/02/11 17:25, jrl wrote:
Robert,
All this said Robert, your clarification is helpful, and I thank you for that.
Architecturally, my picture of a Zone (transition), as an individual element/object/entity for any given period of time will have a fixed beginning and ending. The end is when the new transition starts or for lack of one, it ends here and now.
From that point of view, "max" is appropriate because for that entity (one with a fixed beginning and ending), the process of determining the transition via a given date, will discard the old object for the new one, making the previous "max" valid but for a transition that is no longer valid.
Consider the picture as it would look in 1999, before the PRC transition, [for Macau].
--- as of Nov 1999 --- Rule Macau 1978 1980 - Apr Sun>=15 0:00 1:00 S Rule Macau 1978 max - Oct Sun>=15 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:20 - LMT 1912
The word "max" would be entirely appropriate. By your current listing, when PRC became relevant, it was then necessary to remove the "max" and put in something else... say 1980. I would argue to leave it as it would have been at that time. The addition of the new transition would negate the effect of the "max" and there would be no need for a change at that time.
For the "TO" field, "max" could be replaced with "1980" as soon as it became known that daylight savings time no longer applied after 1980. Setting "TO" to "max" indicates there is an "empty" transition (from standard time to standard time) every year in October from 1981 onwards until the Macau rules are no longer used (after 1999). Setting "TO" to 1980 gets rid of these useless empty transitions. The Asia/Macau zone indicates that the "Macau" rules applied from 1913 until 1999 Dec 20 with a GMT offset of 8:00 and a format of "MO%sT". This is the offset and format that is used before the first transition and after the final transition. One thing that is not clear to me at the moment is how the "%s" part of a zone's format is expanded before the first transition and after the final transition of a rule set. But I'm sure this would become clear if I studied the zic source code a bit more!
Regards, Jamie
-----Original Message----- From: kre@munnari.OZ.AU [mailto:kre@munnari.OZ.AU] Sent: Tuesday, February 22, 2011 10:44 AM To: tz@lecserver.nci.nih.gov Subject: Re: Macau
Date: Tue, 22 Feb 2011 13:19:26 +0000 From: jrl <jrl@terraatlas.com> Message-ID: <E468A544C5BEF74DBF22CAAB3FD50DE810F48C13@UNIVERZ.terraatlas.local>
| Meaning use the Macau rules until Dec 20, 1999 | There are no Macau Rules after October of 1980.
Yes.
| SO... in my mind it means we revert to the overall rule of the Zone
No, no rules means no transitions, the time just continues forward (like the clock on your wall) without any strange jumps. Whenever the time jumps, we need a transition point, the rules say when those transition points appear.
| If there are no rules, then revert back to the rule of the Zone.
Where do you think the documentation says that? Because if there is somewhere, we need to fix it, because that's not how it works at all. The rules give the method for finding the transition points, when there is no transition point, time just moves forward, as time always has.
| What doesn't make sense if why a set of Rules is used that ends prior | to the end of the period used by the zone.
Because there was a period when there were transitions, and that period ended, the rules cover the period of transitions.
| Perhaps a "max" in place of the 1980 would make this more clear.
No, just the opposite. We use "max" when we have transitions that are continuing into the future, to some (as yet) undetermined future time. When we know when the transitions stopped occurring, we say so, that is what makes things clear.
Once again, the point of the rules is to provide a method by which we calculate the points at which local wallclock time experiences a non-continuity, and that's it. Nothing else is reasonably possible, as these things are not necessarily nice nested "go forward and back" operations that could be expressed using other means.
kre
ps: you said "the time change ran ends on the Sunday before the 15th for the years 1978, 1979, and 1980" whereas the rule you quoted in the earlier mail was "the first sunday on or after the 15th" (Sun>=15) (a way of saying "the third sunday") - I assume the "before" in your message was just a typo/thinko.
-- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Date: Tue, 22 Feb 2011 17:25:59 +0000 From: jrl <jrl@terraatlas.com> Message-ID: <E468A544C5BEF74DBF22CAAB3FD50DE810F48C92@UNIVERZ.terraatlas.local> | Architecturally, my picture of a Zone (transition), as an individual | element/object/entity for any given period of time will have a fixed | beginning and ending. You're imagining a situation where there is a "standard time" and periods where things are different, and while for many of us that imagination is quite a good match to reality, handling thins this way is simply not general enough. At times there is simply a variation, with no intent of anything every coming back. Take for example the message from Steffen Thorsen just a couple of weeks ago (Feb 8), where he said ... straen@thorsen.priv.no said: | Many news sources report that Russia will move clocks forward for DST as | usual, but not back again, so they will stay permanently on DST, from 2011. If you think of things as occasional (or periodic) variations in the time then you can't handle events like that (which for the purpose of this message I will assume is going to happen, without intending in any way to actually confirm an event about which I have no knowledge whatever.) The transitions in the tzdata are instead the instantaneous discontinuities of wall clock time - those events where the TV news services (etc) all remind everyone "Don't forget to put your clocks back (or forward) before you go to sleep tonight". That alteration of the normal sequence of the flow of time is the transition (a single forward or backward variation) that the rules describe - that's also why each rule describes a one way switch, they don't say "from X until Y the offset will be...", they say "from X, the offset will change to ..." This is what we need to make clear in the documentation, and if there's anywhere that you've seen that suggests the interpretation that you have adopted, please point that out to us so it can be corrected. I'm saying this because this is not an uncommon mistake to make. It may be that there's something in our doc that we aren't seeing that is causing this, or it may be other circumstances. | From that point of view, "max" is appropriate Ian Abbot explained why max doesn't apply - the end of the summer time rules for Macau had nothing at all do do with Macau's return to China, summer time ended almost 20 years before that event after all. abbotti@mev.co.uk said: | One thing that is not clear to me at the moment is how the "%s" part of a | zone's format is expanded before the first transition and after the final | transition of a rule set. But I'm sure this would become clear if I studied | the zic source code a bit more! Yes, this has been one of the hardest parts for people to understand. If I have it right (and here I am not sure that I do), the right wauy to think of it is along the same lines as above - the rules specify transitions, the TZ abbreviation (for whatever value it has, which is not much) starts out at whatever it was before the period during which the rules apply, and continues that way until the fist transition event. Then (perhaps) a different one applies - which continues until the next transition event. And note that transitions either occur periodically (within some limits) as specified by the rules, or as one offs, as specified in the zone - either way we get a transition point, where the offset, abbreviation, and summer time flag, can (together, or individually) alter. kre
I had trouble understanding this as well, so I wrote a little paper about it, mostly for my own benefit: http://www.cstdbill.com/tzdb/tz-how-to.html I've mentioned it a couple of other times on this list, and nobody has corrected me yet. 8-) I think that much of the confusion is due to the rules wanting to be /both/ transitions (most of the rule) /and/ steady states (the SAVE and LETTER columns). I give an example in the paper. Zones are definitely steady states. My understanding is that they're in effect during the half-open interval, [previous line's UNTIL, this line's UNTIL). If there's no previous line, the lower bound is the beginning of time; for the last line, which has no UNTIL, the upper bound is the end of time. 8-) Does that make sense? --Bill
On 22/02/11 23:23, Bill Seymour wrote:
I had trouble understanding this as well, so I wrote a little paper about it, mostly for my own benefit:
http://www.cstdbill.com/tzdb/tz-how-to.html
I've mentioned it a couple of other times on this list, and nobody has corrected me yet. 8-)
Looks good. It'd be great if this (or something like it) could be distributed with tzcode.
I think that much of the confusion is due to the rules wanting to be /both/ transitions (most of the rule) /and/ steady states (the SAVE and LETTER columns). I give an example in the paper.
Zones are definitely steady states. My understanding is that they're in effect during the half-open interval, [previous line's UNTIL, this line's UNTIL). If there's no previous line, the lower bound is the beginning of time; for the last line, which has no UNTIL, the upper bound is the end of time. 8-)
Does that make sense?
--Bill
It makes sense to me. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Great visual... thanks Bill ________________________________________ From: Ian Abbott [abbotti@mev.co.uk] Sent: Wednesday, February 23, 2011 10:48 AM To: tz@lecserver.nci.nih.gov Subject: Re: Macau On 22/02/11 23:23, Bill Seymour wrote:
I had trouble understanding this as well, so I wrote a little paper about it, mostly for my own benefit:
http://www.cstdbill.com/tzdb/tz-how-to.html
I've mentioned it a couple of other times on this list, and nobody has corrected me yet. 8-)
Looks good. It'd be great if this (or something like it) could be distributed with tzcode.
I think that much of the confusion is due to the rules wanting to be /both/ transitions (most of the rule) /and/ steady states (the SAVE and LETTER columns). I give an example in the paper.
Zones are definitely steady states. My understanding is that they're in effect during the half-open interval, [previous line's UNTIL, this line's UNTIL). If there's no previous line, the lower bound is the beginning of time; for the last line, which has no UNTIL, the upper bound is the end of time. 8-)
Does that make sense?
--Bill
It makes sense to me. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
participants (5)
-
Bill Seymour -
David Patte -
Ian Abbott -
jrl -
Robert Elz