Unix leap second table issue #9
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I put in a correction to the atomic_difference which fixes that, but I am wondering if I should always consider system_time to be unix time or maybe it should be unix leap time (if leap seconds are defined). The weird thing is that days are exactly every 24 hours in unix leap time, meaning that the unix leap day is 27 seconds before the unix day, but daylight savings shifts are at the same time, meaning that daylight shifts start at 2:00:27 am in unix leap time. Also, most time zone files ignore the existance of leap seconds. Maybe I should have a leaptimestamp? I am not exactly sure how to best proceed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix issue #8. This is an issue where the right/UTC and other right/ tables record timestamps in "unix leap time" rather than
"unix time" or TAI-10. This means that the leap seconds from the table are offset by the leap second intervals themselves. I am now translating the leap second times back into unix epoch time, but this might not be a satisfying long term solution. It would be nice if I could know if the system time is in unix time or unix leap time.