new time conversion interface

Paul Hill pHill at
Thu Nov 5 18:01:31 UTC 1998

Nathan Myers wrote:

> We're dealing with _humans_, here.  It's a reasonable goal to try to
> increase the reliability of time entries by noting likely errors.
> The reality is that it is extremely common for clocks to go unchanged
> for a few hours (or even a day or two) after the "official" time change.
> (I have shown up for work an hour early myself, as a result; I never
> look at a clock most Sundays.)
> A note that the time changed recently is *extremely* helpful when
> getting confirmation of a time entry, but most programmers are not
> equipped or inclined to root about in a transition database,

Why would a programmer want to?  The programmer asked to please convert the
fields into a timestamp given the TZ provided.  I don't see how going to look
for other transition rules has anything to do with it.  There is still a list of
possible interpretations given just one possible fully accurate TZ definition.
Going looking in a transition DB only provides more entries for the list
returned (An additional entry might capture a possible alternate based on the
possibility that the programmer really did not pass the library the right TZ,
because the library code can see that the given rules did not apply on the date
provided in the time struct.)

> I agree that the two examples are too similar.  Originally I had
> #0 as the canonical "certain" time, and then realized that (as
> you noted) that condition is rare.  At some point the likelihood
> of an error due to a transition becomes smaller than that of a
> simple typo, which can only be determined empirically.

So how are you going to put that fuzzy set in the library code so that sometimes
you can return
a "doubtful subsitution" and sometimes you can return a "possible unofficial

> > At a minimum this appears to suggest that there is a redundancy in
> > your proposed catagories, but maybe I don't completely understand
> > the use of the two offsets, which also differ between the two
> > possibilities, but I can't see why they would.
> Consider #0, then, to be the case the day after the time change.
> Two days after, we can say that a simple data entry "typo" is
> equally likely and drop the alternative.

You are loosing me here.
Would the time in question be a time that appears to be near the time change but
actually asked to be converted (or re-examined) two days later, or would the
time in question be a time that is two days later?

> > Speaking of ambiguity, could you explain what your are really trying
> > to capture in #1 and #2, because your descriptions are of the same
> > circumstance.  Maybe you meant #1 is one half hour after the time
> > change ("2:30" is a Standard Time) and #2 is one half-hour before
> > the time change ("2:30" is a DLS Time). If so, these are also the
> > result of reading a clock that wasn't reset correctly and putting
> > that value in the tm struct, so why are your return results different
> > by more than just a sign in the offset.
> Er, that's a typo.  (Note the hour of the posting. Ironic, isn't
> it? :-)  My apologies for the confusion.  In the original posting
> I had two lists and it was correct in the first list, but transcribed
> wrong.
> The intended entry for #2 was 03:30.  This is a valid "official"
> time, unlike 02:30.  However, it is very likely to be wrong.

But that makes the #2 entry jibberish, if I rewrite it as:

 2. Spring ambiguity, enter 03:30 when it doesn't exist because
   civil time proceeded 01:59:59 -> 03:00:00 (or whatever).

Say what?   3:30 does exist in DLS, but it might be an old time in ST.
Maybe it should be:
 2. Spring ambiguity, enter 03:30, but that is so close to the change time it is

It would seem you could do the discussion of favor and repost a complete list
of  possible combinations
and what kind of rules you are going to use to put your tags on all of the
different interpreations.

> Cases that are identical as far as the program is concerned
> (time is an hour off because of a clock not reset) are quite
> different in how the user experiences them.

"identical as far as the program is concerned", but you are trying to return two
different values from the "alternative" time.  What magic is used to generate
the lables on the alternatives?  Listing them as alternatives, okay, I see that.
I just don't see how you can the alternatives differently.

> In the #0 your second possibility is "doubtful
> ...  substitution", in #4 you have "possible ... unofficial".

It would seem that that deciding the importance of an alternative as you state
is up to the programmer who called this service, so all you can do is provide

One has to ask: since you have 16 possible return flag combinations, could you
please explain why only 5 of them are covered in your list (and I see only 2),
and what is right or wrong about the other 11, i.e. "doubtful ... unofficial"
etc.  If you only have 5, just have one enum that lists them and not imply
states that don't exist.


More information about the tz mailing list