search

ygale / timezone-olson

A pure Haskell parser and renderer for binary Olson timezone files
BSD 3-Clause "New" or "Revised" License
7 stars 8 forks source link

Time-zone conversions after 2037 wrong #3

Open AshleyYakeley opened 7 years ago

AshleyYakeley commented 7 years ago

I ran this test program:

module Main where
import Data.Time
import Data.Time.LocalTime.TimeZone.Series
import Data.Time.LocalTime.TimeZone.Olson

main :: IO ()
main = do
    tzs <- getTimeZoneSeriesFromOlsonFile "/usr/share/zoneinfo/America/New_York"
    putStrLn $ show $ timeZoneFromSeries tzs $ UTCTime (fromGregorian 2038 7 1) 0

Result:

EST

By comparison, the C library correctly gives EDT:

$ env TZ=America/New_York date -d '2038-07-01 UTC'
Wed Jun 30 20:00:00 EDT 2038
AshleyYakeley commented 7 years ago

I believe the olsonPosixTZ field determines how the clocks are changed for days after all the explicit transitions. However, there seems to be no place in TimeZoneSeries for this information.

AshleyYakeley commented 7 years ago

This seems to be the best specification of the old POSIX TZ format: http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

ygale commented 7 years ago

Thanks! Yes, TimeZoneSeries currently does not support rules for transitions beyond those that are listed explicitly.

It would be even nicer for TimeZoneSeries to support the more general rules in tzdata source files. That would make it possible to write an alternative tzdata compiler in Haskell. The extra layer of correctness verification provided by Haskell's type system would be very appropriate for such a critical piece of basic infrastructure.

In any case, this would be a breaking change in TimeZoneSeries, although it would not break code that only uses the functions provided and does not access the constructor directly.