[local-time-devel] encode-timestamp : wrong offset at DST transition

Thomas Munro munro at ip9.org
Fri Jan 20 01:19:39 UTC 2012


Hi Siebe,

I have only just seen your message from May 2011, about finding the
appropriate offset when you have a timezone and a time, including
analysis of the problem and earlier patches.  About my proposal from
May 2009, you wrote:

> - inefficent: the transition table is used after guessing

I agree.

> - inefficient: too much consing, too many timestamp to unix-time conversions
(involving bignums), ...

I agree.

> - unfriendly: no useful fallback when the requested time is invalid

I agree.

Your proposal looks vastly more efficient (assuming it gives the right
answers which I didn't check).  Regarding the questions you raise
about dealing with ambiguities and so forth, I thought about this
problem a bit after I last wrote to this list, and concluded that the
ideal interface would let the end user control the conversion with an
explicit policy and a reasonable default, or allow the user to receive
a list results (usually containing one, but maybe empty or many).  I
did some (unfinished, inefficient, educational but useless)
prototyping of that idea in an Emacs Lisp function called
clock-utc-time->posix-seconds*:

https://github.com/macdice/protocolarium/blob/master/clock.el#L879

Perhaps you could find an efficient way of exposing a set of policies
like these (:any, :prefer-daylight-savings, ...) if you aren't
satisfied with following the approach taken by POSIX mktime (with
tm_issdt == -1) and others (which is to ignore the problem of
ambiguity and make an arbitrary choice).

Thanks,

Thomas Munro





More information about the local-time-devel mailing list