On Tue, Jun 07, 2005 at 09:56:22PM -0700, Andreas Raab wrote:
> Hi Lex,
<snip> 
> > Regarding the spec, though, the timezone interface sounds fishy.  It is
> > reporting an offset, but the offset changes over time.  So, (a) you have
> > to call the offset primitive every time you want to do any timezone
> > computation, and (b) even then there is a race condition, and the offset
> > might change between the time you query it and the time you use it. 
> > Sure you will usually win this race, but is it a good idea to *design*
> > an unavoidable race condition into the spec?
> 
> I disagree. I think you're going way beyound what's likely and 
> reasonable here. Contrary to my cell phone (which actually determines 
> the time zone it is in when I leave the plane and turn it back on) I 
> have yet to see a laptop or desktop which does that. Because of that the 
> question whether there is a race condition or not is irrelevant, plain 
> and simple. Even if the time zone *does* change, and even if the machine 
> *did* determine whether it is in a new time zone or not, reacting to 
> this change is nothing that has any sort of realtime constraints. In 
> reality, all people I've met on airplanes use either the start or the 
> destination time zone and don't care one iota about intermediate time 
> zones. (btw, we *did* consider this question when we talked about the 
> interface and considered it irrelevant)

Andreas, the potential race condition is present because the TZ offset
changes as a function of time for any given timezone, not because the
timezone itself may be changed (which of course is also possible).
Specifically, the value of the offset changes at daylight savings
time transitions (and leap second transitions if you wanted to be
really picky about it).

You are correct that this is of little practical consequence, but I
think that Lex's point is that it is a shame to do this wrong when
it would be just as easy to do it right.

FWIW, my own personal opinion is carry on as planned. The timezone
offset primitive is useful, and it's better to get it almost right
than to leave it completely wrong for another five years.

Dave

p.s. A minor nit in case this is not yet fully implemented:
Timezone offsets should be reported in units of seconds (or
minutes), rather than hours. There is no need to use a float
to handle this.  I can't think of any specific case where this
would be a problem, but it seems possible that using a float
could introduce numeric precision issues e.g. when comparing
two times for equality.

The widely used timezone tables represent the offset in units
of seconds, while some (maybe obsolete) gettimeofday()
implementations use minutes. We should use seconds, and have
the primitives answer integer values rather than floats.