[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