On Wednesday, November 15 2000, "Paul Eggert" wrote to "lennox@cs.columbia.edu, tz@elsie.nci.nih.gov" saying:
<http://www.cs.columbia.edu/~lennox/draft-ietf-iptel-cpl-04.txt>.)
From the tz list's point of view, Appendix A of that draft is perhaps the most interesting one. But frankly I couldn't follow it -- I have a vague impression of what it's doing, but I couldn't make heads or tails of it really, even though I read the earlier part of the RFC. Some examples would help immensely.
There's Java code available at <http://www.cs.columbia.edu/~lennox/Cal-Code/>, which implements the algorithm of Appendix A. This may be more comprehensible. The short description of the algorithm is: we have an instant of time and a recurrence rule of time periods, and we want to find out if the former falls within an instance of the latter. To do this, we determine the unique period which a) possibly could be one of the repititions of the rule, and b) possibly could contain the time instant. (By constraining the structure of rules various ways, we guarantee that this period is unique). Then we check whether both points A and B are actually true. I admit this algorithm approaches the problem somewhat "backward" -- it had to, in order to get an O(1) solution to it. (The obvious solution would have been just to enumerate every recurrence of the rule, until we pass the instant.)
I did notice this point:
1. Compute the time of the call, in the timezone of the time switch. (No step after this needs to consider time zones -- all calculations are done using continuously-running standard Gregorian time.)
Suppose the current time zone is America/Los_Angeles, the time of the call is 2000-04-02 01:30 -0800 (PST), and you have a two-hour time slot. (As I don't follow your terminology, I'm using informal terms like "time slot".) Since you use standard Gregorian time, I guess you'll say that 2000-04-02 03:45 -0700 falls within the two-hour time slot. But 03:45 actually is only 1 hour and 15 minutes after the time of the call, due to a DST change. Is that what the user wants?
I think it is, given that the purpose of the CPL is to make decisions about how a user's phone calls are routed. For example, imagine that a user has the rule "I don't want my phone to ring between 10 pm and 7 am." In the language of the CPL (which is derived from iCal's recurrence rules), this is stated either as something like "2000-11-16, 10 pm - 2000-11-17, 7am; repeat daily" or as something like "2000-11-16, 10 pm, for 9 hours; repeat daily". Now, the question is what the user would expect to have happen the morning of April 1, 2001 (assuming your example of America/Los_Angeles) and on subsequent transitition dates. You could argue that the behavior should be different in the two cases, and for the latter representation that the block should actually stop working at 6 am on that day. However, I felt it was much more likely that the semantics of the two cases are actually intended to be the same thing; and having a phone ring at 6:30 am on April 1st, or having it not ring at 7:30 am on October 28, 2001, would violate the principle of least surprise.
As an extreme case, consider Pacific/Kiritimati. In that time zone there is no day 1995-01-01, as they moved the clock 24 hours ahead at midnight. What will Algorithm A do with that case? There are also cases of clocks moving backwards 24 hours.
It should handle it correctly, as far as I know -- it just takes the current instant and derives the current civil time from it, which is always a valid (albeit not one-to-one) operation. The assumption the algorithm makes is that the user's desired treatment of their phone calls is determined by the current civil date and time, not by the passage of time in a monotonically running clock. Thus, if something special happens on Sundays in Kiritimati, it just didn't happen that week. Likewise, American expats in Samoa in 1879 had their celebrations of the Fourth of July twice (not that there were likely too many telephones there at that point). I probably should have included rather more text in the specification explaining these considerations; and I probably should have run it by the TZ list sooner. Unfortunately, given the stage the document is at in the IETF standardization process, it's somewhat late to add it now. -- Jonathan Lennox lennox@cs.columbia.edu