4 ms·

Why are these options mutually exclusive? Is there some technical limitation here preventing us from having one monotonic clock and a separate orbital clock?

greglindahl 11y ago
Both of those already exist, and in fact the GPS system uses the orbital clock, for obvious reasons. People are arguing about the default... always fruitless.
jepler 11y ago
The UNIX 'zoneinfo' format is flexible enough to incorporate second offsets, so this can be done on many systems today (Linux, *BSD (the latter including, I assume, OS X)). The system clock would be kept in TAI (or maybe GPS, which is a fixed number of seconds different than TAI?) and the local time is calculated by applying a timezone offset in seconds. http://www.ucolick.org/~sla/leapsecs/right+gps.html http://www.ucolick.org/~sla/leapsecs/right+gps.html
- urbit 11y ago
  Given that the leap-second problem exists, this is the right technical way to deal with it. Unfortunately I've never seen anyone doing this, but they should. (Of course it'd be ideal if humans were willing to abandon their silly timezones, and just plan schedules in absolute time that made sense for their geography. Alas, not sure we're ready as a species for this level of change.)
TazeTSchnitzel 11y ago
No, but there's always going to be a standard time, and that one slowly becomes meaningless if we let it drift out of sync with the Earth.
- andrew-lucker 11y ago
  http://physics.nist.gov/cuu/Units/second.html http://physics.nist.gov/cuu/Units/second.html Seconds have been independent of solar time for quite a while.
Jach 11y ago
From https://github.com/urbit/urbit/blob/master/include/vere/vere.h#L582 https://github.com/urbit/urbit/blob/master/include/vere/vere... /* Urbit time: 128 bits, leap-free. ** ** High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012) ** Low 64 bits: 1/2^64 of a second. ** ** Seconds per Gregorian 400-block: 12.622.780.800 ** 400-blocks from 0 to 0AD: 730.692.561 ** Years from 0 to 0AD: 292.277.024.400 ** Seconds from 0 to 0AD: 9.223.372.029.693.628.800 ** Seconds between 0A and Unix epoch: 62.167.219.200 ** Seconds before Unix epoch: 9.223.372.091.860.848.000 ** The same, in C hex notation: 0x8000000cce9e0d80ULL ** ** New leap seconds after July 2012 (leap second 25) are ignored. The ** platform OS will not ignore them, of course, so they must be detected ** and counteracted. Perhaps this phenomenon will soon find an endpoint. */
- greglindahl 11y ago
  There's a standard for what this is trying to do: TAI, or TAI with an offset of 19 seconds, like GPS. Rolling your own is never a good idea.
  - urbit 11y ago
    Yes, this equates to TAI minus 35 seconds. GPS did exactly the same thing (instantiated at a TAI offset equal to UTC), perhaps in a vain hope that the astronomers would give up their death-grip on time. Not sure the difference between 35 and 19 amounts to "rolling your own." (At least future decisions are out of the hands of the astronomers and into the hands of the timekeepers, so maybe these responsible authorities will just refuse to declare further leap seconds regardless of heavenly tantrums.) The comment just describes a trivial notation for representing 128-bit TAI as an unsigned integer. The closest comparable "standard" that I know of is DJB's TAI64 [1]. (Everything released by DJB should be regarded as a standard.) But TAI64 is (a) defined as a bytestream, not a uint128_t; and (b) has a hopelessly complicated fractional subsecond system. [1] http://cr.yp.to/proto/tai64.txt http://cr.yp.to/proto/tai64.txt.
    - greglindahl 11y ago

greglindahl 11y ago

Both of those already exist, and in fact the GPS system uses the orbital clock, for obvious reasons. People are arguing about the default... always fruitless.

jepler 11y ago

The UNIX 'zoneinfo' format is flexible enough to incorporate second offsets, so this can be done on many systems today (Linux, *BSD (the latter including, I assume, OS X)). The system clock would be kept in TAI (or maybe GPS, which is a fixed number of seconds different than TAI?) and the local time is calculated by applying a timezone offset in seconds. http://www.ucolick.org/~sla/leapsecs/right+gps.html http://www.ucolick.org/~sla/leapsecs/right+gps.html

urbit 11y ago
Given that the leap-second problem exists, this is the right technical way to deal with it. Unfortunately I've never seen anyone doing this, but they should. (Of course it'd be ideal if humans were willing to abandon their silly timezones, and just plan schedules in absolute time that made sense for their geography. Alas, not sure we're ready as a species for this level of change.)

TazeTSchnitzel 11y ago

No, but there's always going to be a standard time, and that one slowly becomes meaningless if we let it drift out of sync with the Earth.

andrew-lucker 11y ago
http://physics.nist.gov/cuu/Units/second.html http://physics.nist.gov/cuu/Units/second.html Seconds have been independent of solar time for quite a while.

Jach 11y ago

From https://github.com/urbit/urbit/blob/master/include/vere/vere.h#L582 https://github.com/urbit/urbit/blob/master/include/vere/vere... /* Urbit time: 128 bits, leap-free. ** ** High 64 bits: 0x8000.000c.cea3.5380 + Unix time at leap 25 (Jul 2012) ** Low 64 bits: 1/2^64 of a second. ** ** Seconds per Gregorian 400-block: 12.622.780.800 ** 400-blocks from 0 to 0AD: 730.692.561 ** Years from 0 to 0AD: 292.277.024.400 ** Seconds from 0 to 0AD: 9.223.372.029.693.628.800 ** Seconds between 0A and Unix epoch: 62.167.219.200 ** Seconds before Unix epoch: 9.223.372.091.860.848.000 ** The same, in C hex notation: 0x8000000cce9e0d80ULL ** ** New leap seconds after July 2012 (leap second 25) are ignored. The ** platform OS will not ignore them, of course, so they must be detected ** and counteracted. Perhaps this phenomenon will soon find an endpoint. */

greglindahl 11y ago
There's a standard for what this is trying to do: TAI, or TAI with an offset of 19 seconds, like GPS. Rolling your own is never a good idea.
- urbit 11y ago
  Yes, this equates to TAI minus 35 seconds. GPS did exactly the same thing (instantiated at a TAI offset equal to UTC), perhaps in a vain hope that the astronomers would give up their death-grip on time. Not sure the difference between 35 and 19 amounts to "rolling your own." (At least future decisions are out of the hands of the astronomers and into the hands of the timekeepers, so maybe these responsible authorities will just refuse to declare further leap seconds regardless of heavenly tantrums.) The comment just describes a trivial notation for representing 128-bit TAI as an unsigned integer. The closest comparable "standard" that I know of is DJB's TAI64 [1]. (Everything released by DJB should be regarded as a standard.) But TAI64 is (a) defined as a bytestream, not a uint128_t; and (b) has a hopelessly complicated fractional subsecond system. [1] http://cr.yp.to/proto/tai64.txt http://cr.yp.to/proto/tai64.txt.
  - greglindahl 11y ago