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

Slightly inaccurate TAI block start times #2

Closed
qntm opened this issue Nov 1, 2016 · 1 comment
Closed

Slightly inaccurate TAI block start times #2

qntm opened this issue Nov 1, 2016 · 1 comment
Assignees

Comments

@qntm
Copy link
Owner

qntm commented Nov 1, 2016

The beginning of TAI for our purposes was 1961-01-01 00:00:01.422818000 TAI, which is -283996798577.182 TAI milliseconds. t-a-i calculates this figure internally as Date.UTC(1961, JANUARY, 1, 0, 0, 1, 422) + 0.818000.

However, strictly speaking, this figure cannot be represented exactly as a 64-bit IEEE 754 float. The number actually stored is the closest float to this value, which is -283996798577.1820068359375. This figure comes some 0.0000068359375 seconds before TAI began. This doesn't seem like a huge problem in the scheme of things, but if an instant in time is considered to be on the wrong side of one of these boundaries, then the wrong computation can be applied to it, and a visibly wrong result can come back. In this specific case, what should happen if we attempt to convert this value to Unix time is that an exception should be thrown, because it is too early. What actually happens is that the conversion is carried out with no problems!

Around half of the figures used for TAI block start points prior to 1972 are faulty in this way.

Instead of storing the closest 64-bit float to the beginning of a TAI block, we should store the next lowest available 64-bit float. In this case, the next float is -283996798577.18194580078125, which comes 0.00005419921875 seconds after TAI began. Not all of those decimal places are necessary, the smallest unambiguous representation for JavaScript's purposes is -283996798577.18195.

It is probably also a good idea to use these values explicitly rather than computing them using Date.UTC() and adding a fraction on.

@qntm qntm self-assigned this Nov 1, 2016
@qntm
Copy link
Owner Author

qntm commented Nov 1, 2016

Computing the "next float" in JavaScript is kind of difficult, but after crunching some numbers by hand, here's a full listing of the values which should be used:

1961-01-01 00:00:01.422818000 = - 283996798577.18195
1961-08-01 00:00:01.647570000 = - 265679998352.43
1962-01-01 00:00:01.845858000 = - 252460798154.142
1963-11-01 00:00:02.697278800 = - 194659197302.7212
1964-01-01 00:00:02.765794000 = - 189388797234.206
1964-04-01 00:00:02.983730000 = - 181526397016.27
1964-09-01 00:00:03.282018000 = - 168307196717.982
1965-01-01 00:00:03.540130000 = - 157766396459.87
1965-03-01 00:00:03.716594000 = - 152668796283.40598
1965-07-01 00:00:03.974706000 = - 142127996025.29398
1965-09-01 00:00:04.155058000 = - 136771195844.94199
1966-01-01 00:00:04.313170000 = - 126230395686.82999
1968-02-01 00:00:06.185682000 = -  60479993814.31799
1972-01-01 00:00:10.000000000 =    63072010000
1972-07-01 00:00:11.000000000 =    78796811000
1973-01-01 00:00:12.000000000 =    94694412000
1974-01-01 00:00:13.000000000 =   126230413000
1975-01-01 00:00:14.000000000 =   157766414000
1976-01-01 00:00:15.000000000 =   189302415000
1977-01-01 00:00:16.000000000 =   220924816000
1978-01-01 00:00:17.000000000 =   252460817000
1979-01-01 00:00:18.000000000 =   283996818000
1980-01-01 00:00:19.000000000 =   315532819000
1981-07-01 00:00:20.000000000 =   362793620000
1982-07-01 00:00:21.000000000 =   394329621000
1983-07-01 00:00:22.000000000 =   425865622000
1985-07-01 00:00:23.000000000 =   489024023000
1988-01-01 00:00:24.000000000 =   567993624000
1990-01-01 00:00:25.000000000 =   631152025000
1991-01-01 00:00:26.000000000 =   662688026000
1992-07-01 00:00:27.000000000 =   709948827000
1993-07-01 00:00:28.000000000 =   741484828000
1994-07-01 00:00:29.000000000 =   773020829000
1996-01-01 00:00:30.000000000 =   820454430000
1997-07-01 00:00:31.000000000 =   867715231000
1999-01-01 00:00:32.000000000 =   915148832000
2006-01-01 00:00:33.000000000 =  1136073633000
2009-01-01 00:00:34.000000000 =  1230768034000
2012-07-01 00:00:35.000000000 =  1341100835000
2015-07-01 00:00:36.000000000 =  1435708836000
2017-01-01 00:00:37.000000000 =  1483228837000

qntm added a commit that referenced this issue Nov 2, 2016
As per issue #2. Will probably have to do the same for Unix block start
times as per #3. And end times, in fact, since the Unix block end time
*isn't* the same as the start time of the previous block... it's not
even a precise number of Unix seconds offset, it's a precise number of
*TAI* seconds offset!!
@qntm qntm closed this as completed Nov 2, 2016
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

1 participant