search

dlowe-net / local-time

Time manipulation library for Common Lisp
Other
102 stars 43 forks source link

Bug specifying timezone in encode-timestamp #92

Closed samuel-jimenez closed 2 months ago

samuel-jimenez commented 4 years ago

(encode-timestamp 0 0 0 3 01 11 2020 :timezone (find-timezone-by-location-name "CST6CDT")) gives @2020-11-01T08:00:00.000000Z when it should return @2020-11-01T09:00:00.000000Z

samuel-jimenez commented 4 years ago

I understand the ambiguity between the hours of 0100 and 0200 local, since 0100 could return 2020-11-01T07:00:00.000000Z or @2020-11-01T06:00:00.000000Z, depending on which occurrence it is. It could be argued that 0200 really should map to @2020-11-01T08:00:00.000000Z, but that is not really germane to this issue. However, (encode-timestamp 0 0 0 7 01 11 2020 :timezone (find-timezone-by-location-name "CST6CDT")) does give the correct response of @2020-11-01T13:00:00.000000Z, which implies that the transitions are tested in UTC, then the offset is applied.

chaitanyagupta commented 1 year ago

+1 - I have observed the same issue around DST transitions. Don't know if the linked PR fully fixes the problem as I don't know enough about timezone handling, but it would be great if this issue were fixed.

mmontone commented 5 months ago

This returns correct result now apparently in current implementation:

LOCAL-TIME> (encode-timestamp 0 0 0 3 01 11 2020 :timezone (find-timezone-by-location-name "CST6CDT"))
@2020-11-01T09:00:00.000000Z