`DateTime` arithmetic on `Microsecond` (or smaller) scale

Internals & Design
,
30

@Oscar_Smith

brought up an argument for why it shouldn’t error - namely, imagine using DateTime and its arithmetic as the time variable in an ODE.

DateTime shouldn’t be used for time intervals (UTM though is there for that); nor then I think ODEs.

DateTime is for ISO 8601 timestamps, as documented; I guess for 8601-1 (going forward, not yet documented as such I believe), as opposed to 8601-2:

https://www.isotc154.org/posts/2019-08-27-introduction-to-the-new-8601/

ISO 8601 is now a family of standards:

  • ISO 8601-1:2019 is the direct successor to ISO 8601:2004
  • ISO 8601-2:2019 provides extensions on top of ISO 8601-1:2019

For UX reasons, consider an ODE (e.g. a pandemic model) where the time variable is represented as a datetime. Suppose the ODE solver takes a time step of 1 day, 2 minutes and 300 microseconds. Should that throw an error or just round to 1 day 2 minutes?

I’m still sort of curious, for a pandemic model, wouldn’t “1 day 2 minutes” be enough, even just “1 day”, or if not, you can go down to millisecond durations (with UTM).

You most often construct DateTime from text, then no problem, no possibility of rounding (currently), you can construct down to the millisecond the representation supports, and also down microseconds (non-default option); it’s just impossible down to nanoseconds, without changing the representation.

@JeffreySarnoff eps for DateTime “is always Millisecond(1)” because why? Would you go with changing it to Microsecond(1), since it’s possible? Most users of DateTime are just storing timestamps and not caring too much, might never do any calculations on them. I’m not even sure what ISO 8601 says about that, since we get wrong durations out:

julia> DateTime("2015-10-01T00:00:01.000") - DateTime("2015-09-30T23:59:59.000")  # ok
2000 milliseconds

julia> DateTime("2015-07-01T00:00:01.000") - DateTime("2015-06-30T23:59:59.000")
2000 milliseconds

That seem to be the same durations, 2 sec, but the latter is wrong since June 30, 2015 had a leap-second added, and thus the latter duration is 33% off. ISO 8601 doesn’t have that concept; since it’s meant for time-stamps, and nobody cares then.

For some applications we care about durations, and/or DateTime timestamp accuracy, but for most it seems silly to worry about if eps is in milliseconds or microseconds, when durations can be off by a sec, or more, since they add up. Also while your clock may be synced up to milliseconds with NTP, it may not be (and off my a lot), and if it is, is it actually accurate to microseconds?

From 2035, leap seconds will be abandoned for 100 years or so and will probably never return. It’s time to work out exactly what to do with a problem that has become increasingly urgent, and severe, with the rise of the digital world.

Why do we have leap seconds?

It’s important to be able to do what you state, including most importantly order them, but were they and ISO 8601 it’s based on ever meant to support anything more, such as offsetting?

Why, do you have an appointment after year 9999? :slight_smile: While I can construct higher (and probably shouldn’t be able to) up to typemax, I can’t construct typemin (nor even just negative years):

julia> DateTime("-146138511-01-01T00:00:00")  # We will never be able to construct the supposed Big Bang (I no longer believe in), with the current Int64.
ERROR: ArgumentError: Invalid DateTime string

[ISO 8601 was limited to the Gregorian calendar, i.e. 1582, no longer is, using “proleptic”, or allows. This should be the min we allow: DateTime("100-01-01T00:00:00") opening up YY possibility to mean 20YY later.]

julia> DateTime("-146138511-01-01T00:00:00")
ERROR: ArgumentError: Invalid DateTime string
1 Like