Bug when converting local time to UTC, near transition to/from daylight saving time

[bakketun]

This is a clarification of the issue reported in #47.

CL-USER> (defun utc-string (timestamp)  (local-time:format-timestring nil timestamp :timezone local-time:+utc-zone+))
UTC-STRING
CL-USER> (defparameter *cet* (local-time:find-timezone-by-location-name "Europe/Stockholm"))
*CET*
CL-USER> (utc-string (local-time:encode-timestamp 0 0 0 0 30 3 2014 :timezone *cet*))
"2014-03-29T23:00:00.000000Z"  ; correct, CET is 1 hour ahead of UTC
CL-USER> (utc-string (local-time:encode-timestamp 0 0 0 4 30 3 2014 :timezone *cet*))
"2014-03-30T02:00:00.000000Z"  ; correct, CET with dayligth saving time is 2 hours head of UTC
CL-USER> (utc-string (local-time:encode-timestamp 0 0 0 1 30 3 2014 :timezone *cet*))
"2014-03-29T23:00:00.000000Z"  ; incorrect, dayligth saving time transititon is not until 2.

The root cause of this bug is that the internal function %guess-offset finds the wrong subtimezone when the local time is near the transition to/from daylight saving time. Converting from UTC to local time is always correct, but going the other way is not as easy because the transition times in are in UTC. To complicate thing even further, when the local time is adjusted backwards, there is a period where the same local time correspond to two different UTC time stamps.

Not sure how to best solve this problem. The code in glibc for doing this conversion is quite tricky to understand: https://github.com/lattera/glibc/blob/master/time/mktime.c

One obvious solution would be to simple call mktime, but this doesn't work since mktime doesn't take a time zone parameter.

[dlowe-net]

There's a reason it's called guess-offset. If you want to encode a timestamp and you know what the offset should be, you are encouraged to use the :offset parameter instead.

[mmontone]

Last expression evaluates to this in current implementation:

LOCAL-TIME> (utc-string (local-time:encode-timestamp 0 0 0 1 30 3 2014 :timezone *cet*))
"2014-03-30T00:00:00.000000Z"

Which seems correct. So the bug may be gone.

[mmontone]

I've written a (currently passing) test for this, for if there's an interest in adding to the codebase:

(deftest test/dst/cases ()
  ;; https://github.com/dlowe-net/local-time/issues/67
  (let ((cet (find-timezone-by-location-name "Europe/Stockholm")))
    (let ((t1 (encode-timestamp 0 0 0 0 30 3 2014 :timezone cet))
          (t2 (encode-timestamp 0 0 0 4 30 3 2014 :timezone cet))
          (t3 (encode-timestamp 0 0 0 1 30 3 2014 :timezone cet)))
      (is (timestamp= t1
                      (encode-timestamp 0 0 0 23 29 03 2014 :timezone +utc-zone+)) "CET is 1 hour ahead of UTC")
      (is 
          (timestamp= t2
                      (encode-timestamp 0 0 0 02 30 03 2014 :timezone +utc-zone+))
          "CET with daylight saving time is 2 hours head of UTC")
      (is (timestamp= t3
                      (encode-timestamp 0 0 0 00 30 03 2014 :timezone +utc-zone+))
          "daylight saving time transititon starts at 2"))

    ;; https://github.com/dlowe-net/local-time/issues/47
    (let ((t1 (encode-timestamp 0 0 0 4 30 3 2014 :timezone cet))
          (t2 (encode-timestamp 0 0 0 1 30 3 2014 :timezone cet)))
      (is (= (timestamp-difference t1 t2) 7200) "2 hours difference because of DST"))))