Allow date periods to be represented by Floats

[kbuzby]

Dates currently forces the periods to be integer types which does not allow for functions like 1 day / 2 = 0.5 days or 12 hours even. Is there a way to base date types on the millisecond and the specific type (day,hour,etc) is just the appropriate conversion?

I know this would only work up until the "week" type, but it would allow for better arithmetic of dates types below the week level.

[StefanKarpinski]

It seems to me like allowing fractional types here would be ok. @quinnj?

[stevengj]

The simplest route would be to make all periods ≤ week an immutable wrapper around Float64 rather than Int64. You lose a bit of precision that way (10 bits, to be precise), but you gain in dynamic range — if you have an application where you need more than 2^53 ms, then you probably need more than 2^63 ms too, so the tradeoff will be worth it.

Instead of having DatePeriod and TimePeriod subtypes of Period, we could then have CalendarPeriod (Year etcetera: integers) and TimePeriod (Week etcetera: floats). / would be defined for TimePeriod but not for CalendarPeriod.

Adding a (float) TimePeriod to a Date or DateTime would be truncating, the same as now.

[kbuzby]

If that level of precision was actually required, could some sort of implementation of a BigInt be utilized?
I would certainly lean towards seeing a greater advantage in increasing dynamic range over precision, but then again, I opened the issue and could be a little biased.

[StefanKarpinski]

I feel like this is a really good candidate for have a parametric type since different people have such different needs.

[stevengj]

What is the use case for needing more than 2^53 of a time period in DateTime calculations but not needing more than 2^63? What is the use case for BigInt or BigFloat time precision? To be a good candidate for a parametric type, it would first be useful to identify actual people/applications with these needs.

(2^53 ms is about 280,000 years. Is there a real situation in which you would be measuring, say, 1,000,000 years in milliseconds and need millisecond precision? I'm skeptical. Even so, you could use the CompoundPeriod type for this case.)

[quinnj]

The quick answer is that it was simpler to implement everything in Int64 😄 I'm a big fan of keeping things simple and adding complexity/flexibility later on.

I think the proposal to have TimePeriods wrap Float64s sounds good. Similar to @stevengj, I kind of doubt the utility of a parametric type here as it would dramatically increase the complexity without a ton of gain. Like @stevengj said, the nature of Period types is the difference in precision, allowing one to use CompoundPeriods to achieve greater range + greater precision.

I'll have time to play around with implementing this starting next week.

[kbuzby]

I started playing around with this myself, and have been running into just one major issue when running all of the date test files. I can't figure typemax and typemin for Date and DateTime. Any suggestions on how to get these?

[stevengj]

Won't Date and DateTime still use integers? I thought we were discussing floats only for Period types.

[kbuzby]

Having TimePeriod wrap a float makes the Day and Millisecond types float values which Date and DateTime use via UTD and UTM constructors, respectively.

Should Date and DateTime round and convert the float values to integers?

My fork here if it's easier to look at with the slightly adjusted TimePeriod types.

[stevengj]

Yes, they should truncate (not round).

[quinnj]

Honestly, I wonder if we really need the Instant interface that uses Period types underneath. I know it provides a nice conceptual separation between Instants and TimeTypes, but it really kind of muddles the internals a bit without really being used at all (i.e. the output of dump(dt)).

I say that because we could just have

immutable Date
  value::Int64
end
immutable DateTime
  value::Int64
end

and then not have to worry about using a Float64 Day type to represent a Date. I'll have some more time over the next few days to keep thinking on this.

[Jeffrey-Sarnoff]

fwiw there is an 'always' in "it is bad practice to use floats with dates and/or times."
one reason: the nonuniform, jump-gapped density of increasing floating point values

[quinnj]

This has been open for quite a while now with no progression or discussion. I'm firmly in the camp of keeping everything integer-based, unless someone out there is really willing to go all out and do a full re-implementation based on Floats. I still believe, though, that one of the strengths of our Dates implementation is the amount of functionality and performance we achieve with such small, readable code. Happy to re-open if people feel strongly, but I think we close as decided.