[local-time-devel] ENCODE-TIMESTAMP with a timezone

[Thomas Munro]

Hi Daniel

2009/5/13 Daniel Lowe <dlowe at bitmuse.com>:
> You can get the offset of a particular timezone with the timestamp-subtimezone
> function, given a timestamp of the period you want.

Isn't there a chicken and egg problem here?  Given elements of a local
time and a timezone, I can't make a timestamp because I don't have the
offset, and you're saying that to get the correct offset I need the
timestamp first.

> [...]
> One of the design principles I've had in mind while making the local-time
> library is that the complexity in time representations shouldn't be covered up
> with half-solutions, so I'm afraid the patch isn't going to go in. I've actually
> been planning to remove the guessing of the time offset entirely, defaulting to
> UTC.  It's simply not meaningful, in the context of a timestamp, to have such an
> ambiguity lying around.

That is what my patch attempted to provide: you do not need to
guess/provide the offset (unless you want to), so that this matches
the capabilities of other Oslen-powered time libraries.  If you have
only the timezone (which is obtained from the Olsen zoneinfo name
based on a city, like "America/New_York") and a set of local time
elements, the algorithm I provided will test each possible offset
(usually there are only two) until it finds one which satisfies the
constraint that the resulting timestamp should fall at a Unix epoch
time where the transition table says that the offset in question
applies.  This is the only way that I could think of to resolve that
chicken and egg problem: you need a timestamp to find out the offset,
but you need an offset to make a timestamp (but there is probably a
better way).

> The idea is that a timestamp is an unambiguous representation of a point in
> time. [...]

Understood.  What I am interested in is finding a way to translate
from the normal human description of time ("2008-12-25 12:00:00 in
London") to your unambiguous representation of time (a type of epoch
time), since without it, ENCODE-TIMESTAMP is less useful than libc
mktime for anyone working with a set of historical times expressed as
local times in a given city.

Is it the interface (being able to translate from "2008-12-25 12:00:00
in London" to a timestamp) or the implementation (the test-each-offset
algorithm) that you didn't like?

Thanks
Thomas