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

LeapSecondTable inverse bug? #42

Open
jamesdbrock opened this issue Apr 5, 2016 · 4 comments
Open

LeapSecondTable inverse bug? #42

jamesdbrock opened this issue Apr 5, 2016 · 4 comments

Comments

@jamesdbrock
Copy link
Member

After applying @kim 's patch for #38 to load a LeapSecondTable, I see this.

Lookup UTC -> TAI

> leapSecondTable $ Left $ mkUTCTime (fromGregorian 2015 6 30) (hhmmss 23 59 59)
35s

Lookup (UTC -> TAI) -> UTC

> leapSecondTable $ Right $ mkUTCTime (fromGregorian 2015 6 30) (hhmmss 23 59 59) ^. absoluteTime leapSecondTable 
36s

I think both expressions should return 35s? Is this a bug?

@jamesdbrock
Copy link
Member Author

Here is a better explanation.

$ stack ghci --package http-conduit --package thyme
> :module + Data.Thyme Data.Thyme.Clock.TAI Data.Thyme.Time.Core Network.HTTP.Conduit Data.ByteString.Lazy Control.Lens Data.AffineSpace
> leapSecondTable <- parseTAIUTCDAT . toStrict <$> simpleHttp "http://maia.usno.navy.mil/ser7/tai-utc.dat"
> Prelude.putStrLn $ unlines $ fmap (\t -> show t ++ " = " ++ show (absoluteTime leapSecondTable # t)) $ Prelude.take 10 $ Prelude.iterate (.+^ fromSeconds' 0.2) $ mkUTCTime (fromGregorian 2015 6 30) (hhmmss 23 58 48) ^. absoluteTime leapSecondTable
2015-06-30 23:59:23.0 TAI = 2015-06-30 23:58:48.0 UTC
2015-06-30 23:59:23.2 TAI = 2015-06-30 23:58:48.2 UTC
2015-06-30 23:59:23.4 TAI = 2015-06-30 23:58:48.4 UTC
2015-06-30 23:59:23.6 TAI = 2015-06-30 23:58:48.6 UTC
2015-06-30 23:59:23.8 TAI = 2015-06-30 23:58:48.8 UTC
2015-06-30 23:59:24.0 TAI = 2015-06-30 23:58:48.0 UTC
2015-06-30 23:59:24.2 TAI = 2015-06-30 23:58:48.2 UTC
2015-06-30 23:59:24.4 TAI = 2015-06-30 23:58:48.4 UTC
2015-06-30 23:59:24.6 TAI = 2015-06-30 23:58:48.6 UTC
2015-06-30 23:59:24.8 TAI = 2015-06-30 23:58:48.8 UTC

As we increment TAI you can see the that the UTC leap second transition occurs at 2015-06-30 23:58:48.0 UTC, but I'm pretty sure it's supposed to occur at 2015-06-30 23:59:60.0 UTC.

@jamesdbrock
Copy link
Member Author

Iterating UTC and watching TAI, however, looks good, the UTC transition occurs at 2015-07-01 00:00:00.0 UTC.

> Prelude.putStrLn $ unlines $ fmap (\t -> show t ++ " = " ++ show (t ^. absoluteTime leapSecondTable)) $ Prelude.take 9 $ Prelude.iterate (.+^ fromSeconds' 0.1) $ mkUTCTime (fromGregorian 2015 6 30) (hhmmss 23 59 59.6)
2015-06-30 23:59:59.6 UTC = 2015-07-01 00:00:34.6 TAI
2015-06-30 23:59:59.7 UTC = 2015-07-01 00:00:34.7 TAI
2015-06-30 23:59:59.8 UTC = 2015-07-01 00:00:34.8 TAI
2015-06-30 23:59:59.9 UTC = 2015-07-01 00:00:34.9 TAI
2015-07-01 00:00:00.0 UTC = 2015-07-01 00:00:36.0 TAI
2015-07-01 00:00:00.1 UTC = 2015-07-01 00:00:36.1 TAI
2015-07-01 00:00:00.2 UTC = 2015-07-01 00:00:36.2 TAI
2015-07-01 00:00:00.3 UTC = 2015-07-01 00:00:36.3 TAI
2015-07-01 00:00:00.4 UTC = 2015-07-01 00:00:36.4 TAI

@jamesdbrock
Copy link
Member Author

Oh, of course the reason why this behavior is weird is that Data.Thyme.UTCTime doesn't support leap seconds.

@liyang
Copy link
Member

liyang commented Apr 11, 2016

Actually the whole thing is buggy. :-/ There will be a fix soon.

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