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 time"?
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 suspicious. 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 alternatives. 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. -Paul