8000 isn't the leapsecond adjustment exactly the wrong way when comparing UTC times? · Issue #7 · FugroRoames/Chrono.jl · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

isn't the leapsecond adjustment exactly the wrong way when comparing UTC times? #7

New issue
< 8000 p class="text-center mb-4"> Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

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

Jump to bottom
Open
skilchen opened this issue Dec 4, 2017 · 3 comments
Open

isn't the leapsecond adjustment exactly the wrong way when comparing UTC times? #7

skilchen opened this issue Dec 4, 2017 · 3 comments

Comments

@skilchen
Copy link
skilchen commented Dec 4, 2017

Not that i understand the issue of leapseconds very well, so my understanding could be wrong. In my understanding the UTC Day 2016-12-31 has a duration of 86401 seconds not 86399. As far as i understand TAI currently ticks slightly too fast in relation to something like solar mean time.

utc1 = Chrono.Time(1hours, UTCDate(2016, 12, 31))
utc2 = Chrono.Time(1hours, UTCDate(2017, 1, 1))
utc2 - utc1

gives:

86399//1 seconds

but in my opinion it should give:

86401//1 seconds
@andyferris
Copy link
Contributor

Yes, that sounds like a bug.

(See also #5).

@andyferris
Copy link
Contributor

@c42f Are the signs wrong here: https://github.com/FugroRoames/Chrono.jl/blob/master/src/clock.jl#L182 ?

@andyferris
Copy link
Contributor

I've lost track - is this still wrong?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@andyferris @skilchen
0