@RichFelker @laurentbercot @whitequark @eevee TAI is perfectly good. Actual UTC is fine*. POSIX "UTC" is nonsense
-
-
Replying to @erincandescent
@RichFelker@laurentbercot@whitequark@eevee (*A correctly defined time_t for UTF would actually be TAI)1 reply 0 retweets 0 likes -
Replying to @erincandescent
@oshepherd@laurentbercot@whitequark@eevee We're not going to agree on this so let's agree to disagree.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@laurentbercot@whitequark@eevee The important thing is that the clock is continuous and monotonic. This is why POSIX UTC fails1 reply 0 retweets 0 likes -
Replying to @erincandescent
@oshepherd@laurentbercot@whitequark@eevee There are other important things too, like ability to interpret times without ext. data.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@laurentbercot@whitequark@eevee This involves keeping times in their *entry* format. It is the *only* way which works1 reply 0 retweets 0 likes -
Replying to @erincandescent
@RichFelker@laurentbercot@whitequark@eevee Standardizing on any UTx fails for this because timezones do change1 reply 0 retweets 0 likes -
Replying to @erincandescent
@oshepherd@laurentbercot@whitequark@eevee Keeping them in UT1 works just as well. Many times (e.g. server logs) do not care about TZ's.1 reply 0 retweets 0 likes -
Replying to @RichFelker
@RichFelker@laurentbercot@whitequark@eevee For times in the past we have the tables. Problem is for times in the future.1 reply 0 retweets 0 likes -
Replying to @erincandescent
@RichFelker@laurentbercot@whitequark@eevee (esp. considering that 99% time sources are TAI/UTC, keeping clock in UT1 requires tables)1 reply 0 retweets 0 likes
@oshepherd @laurentbercot @whitequark @eevee Twitter is not the right medium for this discussion. And we're not going to agree anyway.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.