new time conversion interface

[Nathan Myers]

Paul Hill wrote: 
> 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.
> > ...
> > 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?  

To minimize mistakes.  Any relevant information the system has that the
user doesn't is a lost opportunity.  People are not (uniformly) stupid,
and can respond usefully to a notification that an entered time is 
dubious.   Likewise, a logged timestamp annotated with reasons to doubt
it may be more useful than a bare timestamp.  The conversion function
has discovered the information, the calling program is equipped to 
decide if it's useful.

> 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.

Current conversion functions don't report a list of possible
interpretations, they report just one.  That's what I'd like
to fix in this interface.

> 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.)

The point is that the conversion function has just looked up all the 
relevant entries.  It can discard any additional information it has
gathered, or report it.  The caller is equipped to choose which of
the additional information is useful, but only if it's reported.
 
> > 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"?

Maybe instead of a "doubtful/possible" flag it just reports how
long before the reported time the last transition occurred, and 
what the conversion would be if that one was missed.

> > > 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. 
> >
> > Er, that's a typo.  ...
> >
> > 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 [gibberish]
> 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
> interpretations.

That might not be the best description of the goal.
The goal is a way for the conversion function to report the
circumstances of the conversion in a form that is easily 
interpreted for different purposes.

In my posting I was too specific about what are still unresolved
design issues.
 
> > 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. 
> ... 
> 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.

It may be that one enum with five values, or with four values and 
a field for when the last time change happened, would be appropriate.  
Again, you have identified a danger of being too specific.  What I 
posted was an (unfortunately confusing) example meant to lend some 
concreteness to the discussion.  

Can we agree that it's useful for the conversion function to 
report (also) the circumstances of the conversion?  Then we can
proceed to explore how to report those circumstances.  

Nathan Myers
ncm at cantrip.org