[local-time-devel] Confused about encode-timestamp, offsets and timezones

[Daniel Lowe]

Arjan Wekking wrote:
> In general I think it would be better to not have the timezone 'offset'
> as a concept in the public API at all (also prevents confusion with
> offset in adjust-timestamp) and deal exclusively with timezones and the
> *default-timezone*.

The encoding "offset" is deliberately there to make developers think about what
they're really trying to do.  We've been discussing entirely removing the
default offset to that end, since it does entirely the wrong thing.  We can't
remove the concept though, because when you encode a time, there's a nasty piece
of ambiguity.

The problem is that a timezone can have different offsets from UTC at different
times, and there's no precise way to implicitly derive an offset.  Consider the
case of 1am before and after daylight savings is in effect.  The
encode-universal-time manages this by having an _optional_ daylight savings
indicator.  All that does is subtract one from the offset, so it was deemed
superfluous for the local-time library.

One solution we might try is to expose an interface for querying the timezone
for its subzones based on name.

We could try having DWIM semantics - a date in January probably isn't going to
run up against daylight savings.  You could probably get away with using the
offset for the date in UTC.  However, one of the goals of the library is to
explicitly expose the problems of time representation, and this is one of them.

Incidentally, encode-universal-time has the same problem.  The sbcl version
tries to guess as well, it just guesses differently than %get-default-offset.

: Daniel :