What will happen to Julia's DateTime type

General Usage
1

Do we need to redefine Julias DateTime type, now that UTC will not follow UT1 anymore?

I guess this will be very tricky to solve. When UTC and UT are beginning to diverge in the future, we probably do not want our default DateTime to be in UT. Of course there is probably no need for immediate action, since it will take decades for both to diverge significantly, but I would be interested if there are already ideas out how to solve potential issues.

2

DateTime already doesn’t deal with leap seconds in UTC, so having leap hours (which DateTime will also ignore) seems even better because they are so infrequent.

3

Well I think the problem is that DateTime currently follows UT which keeps the clocks synchronized with solar noon/midnight by defining a second through the duration of the Earth’s rotation. This way DateTime times were almost in sync with UTC (plus-minus one second). However, in the future UTC, based on a fixed second will slowly drift away from UT so that solar time will not match UTC anymore and therefore Julia’s DateTime and UTC will also start diverging because UTC stops correcting through leap seconds.

4

If that is what the doc says, it seems it has not been fixed since this thread. The understanding there seems to be that a docs fix saying “UTC-like, no leap seconds, not UT1” would be reasonable. The type itself needs no change.

5

This is what I took from the docs:

Both Date and DateTime are basically immutable Int64 wrappers. The single instant field of either type is actually a UTInstant{P} type, which represents a continuously increasing machine timeline based on the UT second [1].

I think it is not super-clear but my takeaway was that it represents UT.