Time handling in CPL (was: Re-entrant, any-zone mktime()-equivalent?)

[Jonathan Lennox]

On Wednesday, November 15 2000, "Paul Eggert" wrote to "lennox at cs.columbia.edu, tz at 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 at cs.columbia.edu