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.

6

If any packages would be affected by this change it would be AstroTime.jl, SolarPosition.jl, and others that rely on knowing the exact position of the Earth at any given moment since UT1 is involved in those calculations (IIRC).

I had heard that this announcment might be coming, but I didn’t know that negative leap seconds were a driver. That is neat!

7

A subtlety is that any time measurement on a computer has uncertainty. So maybe it is UT1 but with one hour errors. If the computer is not connected to the internet the error could be much higher.

8

For time stamping Julia consults the system via ‘now()’ and labels the type with 'UTC". This is overwhelmingly correct, because almost all system clocks are synchronized to UTC via the NTP protocol. Very few systems are synchronized to other time standards (UT1, …), then the UTC label is not quite correct. Anyway, Julia does not really have any control over which time standard applies to time stamps from system clocks.

Similarly, when already time stamped data reach Julia for processing, of course the rules and definitions of these time stamps apply, however they were produced. Again, Julia does not have any built-in time standard (the same applies to Python, SQLite, etc.).

For time arithmetic the DataTime module assumes that every day has 86400 seconds. It fails for valid time stamps like “2016-12-31T23:59:60”. Because presumably the internal clock or external time stamps are UTC, one could, very sloppily, say that “Julia uses UTC without the leap seconds”. It definitely does not use “UT1” because generally it has no access to a UT1 clock.

In a package there might be code, for example, to generate control sequences for a telescope/camera on the ground to photograph the ISS or so. Assuming that this sequence needs UTC time tags, the package has to use an updated table of planned leap seconds in order to produce correct results at any time. Julia does not provide such a table and should not. It should be handled within such packages.