# Define zero for DateTime

#1

Do you even…?

More seriously, it would be useful if we could treat time like any other quantity. Everyone seems to agree that the world started either `now()` ago, or on `00:00 1st January 1970`. Not sure what convention other languages use nor why, but it would be great if we could pick one and move on.

#2

Do you need it for arithmetic? `Dates.Day(0)` would do for most purposes I can imagine.

#3

I just discovered the excellent IntervalTrees.jl. If we were to use it to define intervals based on dates (a reasonable case), then it errors on the inability to get a zero from a `DateTime`. Got me thinking…

#4

By the way, I find it very strange that `DateTime()` gives you 0001-01-01T00:00:00 even though the actual value of `DataTime()` in milliseconds is `1000*60*60*24`. I also don’t understand why either one of these dates should be zero. It would make far more sense if `0000-01-01T00:00:00` were zero. Is this based on some standard?

#5

Agreed.

#6

Does it make sense to add dates? `zero` is the additive identity, i. e., it must hold that `a + zero(a) == a`. It seems to me that it only makes sense if there is such a thing as a relative date. Maybe a bit unrelated, but this highlights an issue that I have run into recently, where some code (also in base) relies on `zero` and `one` to do type promotion (notably `inv(::AbstractArray)`). In this case, a relative date would be of a different type than an absolute date.

#7

There is no year zero as 1BC is followed by 1AD: https://en.wikipedia.org/wiki/Year_zero. Well, at least in the BC/AD system, however, `DateTime(0)` works.

#8

`zero(::Date) = Day(0)` would make sense. `Month(0)` and `Year(0)` would also be correct, but it’s more logical to use the smallest unit.

#9

Well, I don’t know what Pope Gregory would have to say about this, but according to Julia’s `DateTime` there is most definitely a year 0:

``````julia> DateTime() - Dates.Year(1)
0000-01-01T00:00:00
``````

(Yes, we are using a system of measurement created by edict of the pope in the 16th century. The horror.)

#10

I think the way forward (in all dimensions) is to just choose a reference point. This is strongly related to weather we should allow negative dates as well…
Time is a dimension. We can have a reference point, zero, and negative values for all 3 spatial axes. Why not time as well?

#11

#12

Having a zero year in terms of presentation is very different from having a zero moment in terms of representation (i.e. epoch). Julia is very good at separating representation and behavior without sacrificing usability or performance, so let’s not make Matlab’s mistake here and try to make the year zero the epoch just because it seems like the “right” epoch. – that would mean that if we do allow using `Float64` to represent datetimes we would have amazing precision around the birthdate of some historical dude and terribly precision around today.

#13

Well, ok, but then why set the epoch to zero on that particular date? It is still a couple of thousand years ago, so one still needs to tack on a few orders of magnitude to get to modern times. Why not simply conform to Unix time? That seems like the best option to me.

#14

One option is to allow date functions to have an input to specify the epoch. For instance, a user could pass in `:unix_epoch` (maybe this is a default) or `:j2000_epoch` or `:gps_epoch` or `:matlab_epoch`. This is done in some geophysical software where both elapsed time and dates are important. It removes ambiguity and allows a user to place precision where it’s important to them. On the other hand, I can’t tell if this is a solution so broad that it satisfies everybody or if it’s a solution so broad that it satisfies nobody.

#15

@ExpandingMan, I can’t tell if you’re replying to me or not. I’m saying that we should not use some ancient date as an epoch. 1970 is recent enough to be a good epoch. Supporting different epochs would be an interesting possibility (not too hard in Julia), but I’m not sure it would be worth the effort.

#16

It would make much more sense to me to have that be part of the time type, not an input parameter.

#17

Oh. I was confused because since currently t=0 corresponds to `0001-01-01T00:00:00` I had assumed that there was some consensus in regard to that. In that case it sounds like we are in agreement, there seems to be no reason to use anything other than unix time.