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.
Do you need it for arithmetic? Dates.Day(0) would do for most purposes I can imagine.
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…
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?
Agreed.
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.
There is no year zero as 1BC is followed by 1AD: Year zero - Wikipedia. Well, at least in the BC/AD system, however, DateTime(0) works.
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.
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.)
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?
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.
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.
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.
@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.
It would make much more sense to me to have that be part of the time type, not an input parameter.
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.