Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time-zone conversions after 2037 wrong #3

Open
AshleyYakeley opened this issue Nov 20, 2016 · 3 comments
Open

Time-zone conversions after 2037 wrong #3

AshleyYakeley opened this issue Nov 20, 2016 · 3 comments

Comments

@AshleyYakeley
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Owner

ygale commented Jun 4, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants