# Why do time quantities have to be integers?
**URL:** https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864
**Category:** Internals & Design
**Tags:** question
**Created:** [September 13, 2017, 8:52am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864 "2017-09-13T08:52:01Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 13, 2017, 8:52am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/1 "2017-09-13T08:52:01Z")
I suspect this has been asked before, I apologize if that is the case.
Why did we decide to not allow for `Dates.Second(1.5)`?
`1.5Unitful.s` works fine for instance…
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [September 13, 2017, 11:13am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/2 "2017-09-13T11:13:04Z")
See: [https://github.com/JuliaLang/julia/issues/9393](https://github.com/JuliaLang/julia/issues/9393)
I would have preferred floats myself, but no one was willing to do the work.
---
### Author:  [@malmaud](https://discourse.julialang.org/u/malmaud)
#### Post date: [September 13, 2017, 3:55pm UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/3 "2017-09-13T15:55:40Z")
Maybe it would be better to reopen that issue and mark it ‘up for grabs’.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 13, 2017, 6:32pm UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/4 "2017-09-13T18:32:22Z")
By all means, but from reading that issue, it sounds like it’s not clear if it would be such a welcomed change. I could live with the _option_ of doing something like `Second(1.5) → Millisecond(1500)`… Or something similar…
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [September 15, 2017, 12:20am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/5 "2017-09-15T00:20:28Z")
Exact time algorithms require integer valued units of time.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 15, 2017, 7:55am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/6 "2017-09-15T07:55:35Z")
Imagine adding `convert` methods that accept a `Float` and find the most accurate representation of that float via a `Dates.CompoundPeriod`, where the smallest temporal unit, `Nanosecond`, would need to be rounded off (and thus some accuracy would be lost)? Wouldn’t something like that keep the accuracy _and_ allow for things like `Second(1.5)`?
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [September 15, 2017, 9:08am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/7 "2017-09-15T09:08:46Z")
Yes but summing many of those makes the roundoff error accumulate and that ends up with equal time intervals becoming unequal – then transactional contracts can get it wrong. For example, to buy something usually requires that the money is available before the purchase occurs – whenever words like “before” appear, the need for exact time algorithms is important. The potential for mismatch increases with signed timespans.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 15, 2017, 9:34am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/8 "2017-09-15T09:34:06Z")
Yea, that makes sense. But this level of accuracy and the lack of it is well known. Whenever we use floats we know that the accuracy is limited to “single” or “double” etc… If a specific procedure requires the absolute accuracy you’re referring to then the user of that procedure (function, module, package, whatever) should be warned somehow (in the docs?). But I don’t see the harm in including the option of converting from a float to a time period.
So just curious: in the applications you’re thinking of, is temporal quantities defined only in discrete units? If so, what is the shortest quantity? Is it really nanoseconds? If not, how would these applications deal with times that are shorter than that?
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [September 15, 2017, 9:34am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/9 "2017-09-15T09:34:38Z")
(with the understanding that I do not recommend this, you can experiment)
```julia
using Base.Dates
function Base.:(*)(x::AbstractFloat, p::Period)
n = Nanosecond(p)
y = x * n.value
nanos = floor(Int64, y)
micros, nanos = fldmod(nanos, 1000)
millis, micros = fldmod(micros, 1000)
secs, millis = fldmod(millis, 1000)
mins, secs = fldmod(secs, 60)
hrs, mins = fldmod(mins, 60)
dys, hrs = fldmod(hrs, 24)
result = Nanosecond(nanos) + Microsecond(micros) +
Millisecond(millis) + Second(secs) +
Minute(mins) + Hour(hrs) + Day(dys)
return result
end
```
```julia
julia> 1.5 * Second(1)
1 second, 500 milliseconds
julia> sqrt(2) * Day(5)
7 days, 1 hour, 42 minutes, 20 seconds, 258 milliseconds, 945 microseconds, 177 nanoseconds
```
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [September 15, 2017, 9:58am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/10 "2017-09-15T09:58:22Z")
Actually, the temporal quantities in software are modelled either using discrete points at some predetermined resolution or as half-open intervals (while you may see the opposite convention used, it really is more sound to set the open half to be earlier part and close the later part).
There are new financial regulations coming into force in 2018. For high-frequency trading, they specify timestamps resolve to 100 nanosecond increments. In order to do that properly, the time-math needs to be somewhat more resolved. 1 nanosecond time-math is handy.
To resolve timespans finer than the smallest `period` supported by an encoding is difficult when not impossible. It is far easier to extend the refinement of the underlying struct.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 15, 2017, 10:13am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/11 "2017-09-15T10:13:47Z")
Cool. So would you give your blessings to something like this?
- algorithms that need absolute accuracy should only accept actual discrete time periods, in their method signature. So they can’t accept floats or some such.
- algorithms that don’t rely on such high levels of accuracy can accept:
1. a `Number` where their docs say it should be seconds/minutes/etc…
2. a `Unitful.jl` time unit
3. `DatesTime`/`Time` instance
I think #2 is best in the case where accuracy is not an issue. This way whoever needs the accuracy can enforce it, and whoever wants some flexibility can have it.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [September 15, 2017, 10:36am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/12 "2017-09-15T10:36:04Z")
Give me two examples: an algorithm and a task where you want the less careful approach? What if the less careful approach takes just as long to compute as the careful approach?
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 15, 2017, 11:04am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/13 "2017-09-15T11:04:49Z")
I’m not sure what you’re getting at, do you want to prove that any task or algorithm I could come up with is solvable without the option of converting a float to a discrete time period? That’s not very convincing. We can agree that the universe of all the algorithms and tasks that ever were or will be, may include things that neither of us thought of, yet.
My main concern with this post is finding out if there is a reason **not** to include the _option_ of converting a float to a time period. Is it horrible? Will no one use it? Is it counter productive? Etc…
Your task actually helped me realize something: the float I want to convert comes from somewhere. We almost always know what this float is supposed to count (seconds, minutes, etc). We can therefore stick that float inside a `Unitful.Quantity` with the correct unit. So I think that this functionality of converting a float to a `Dates.TimePeriod` should reside in `Unitful.jl`:
```julia
source spits out hours as floats -> Float64(1.2) -> `Unitful.hr` -> `Dates.CompoundPeriod`
```
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 15, 2017, 11:16am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/14 "2017-09-15T11:16:46Z")
Times and dates a mess, and different applications have different requirements. Instead of arguing with people about _their_ requirements, why don’t you just implement _yours_ in a package? This does not need to be in `Base`.
(arguably, even `Base.Dates` could be a package, but I did not find a related “move \* to a package” issue)
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 15, 2017, 11:22am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/15 "2017-09-15T11:22:22Z")
That’s what I concluded with in my last post here. But just to be clear: I don’t think I’m arguing with @JeffreySarnoff about @JeffreySarnoff’s requirements, I’m trying to figure out if there is a true reason to why there is no conversion from floats to times. Now that I’ve cleared that off I can implement it. I.e. copy paste @JeffreySarnoff’s code from above and adding it to `Unitful.jl`…
---
### Author:  [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [September 15, 2017, 11:25am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/16 "2017-09-15T11:25:01Z")
> [@JeffreySarnoff](#):
>
> Exact time algorithms require integer valued units of time.
`Float64` values represent integers up to 2^53 exactly. The idea that integer operations incur roundoff errors in floating-point arithmetic is a myth.
Of course, integers over 2^53 may be rounded, but with `Int64` you will get even more catastrophic overflow effects for integers over 2^63. What time calculations require exact integers over 2^53 but are okay with disasters over 2^63?
---
### Author:  [@nalimilan](https://discourse.julialang.org/u/nalimilan)
#### Post date: [September 15, 2017, 11:36am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/17 "2017-09-15T11:36:23Z")
> [@Tamas\_Papp](#):
>
> (arguably, even Base.Dates could be a package, but I did not find a related “move \* to a package” issue)
>
>
> The \`Dates\` submodule is quite large and has a lot of functionality which is sti…ll very much a work in progress. To that end, it should be split into just the bare minimum functionality that needs to be in Base, which IMO is:
>
> \- type definitions
> \- printing in ISO standard format
> \- some basic arithmetic?
>
> If you want to do anything more complex with dates or times, you'll have to load a (standard) package. The only reason to have dates and times in Base at all is so that functions like \`now()\` can produce datetime values.
>
> Would close (move out of this repo) the following issues:
>
> https://github.com/JuliaLang/julia/issues?q=is%3Aopen+is%3Aissue+label%3Adates
>
> Most of these should technically be a 1.0 blocker. The only viable alternative I can see is to keep \`Dates\` in Base but declare it to be unstable despite the 1.0 release and continue to evolve it.
---
### Author:  [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)
#### Post date: [September 15, 2017, 11:37am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/18 "2017-09-15T11:37:47Z")
> [@yakir12](#):
>
> I don’t think I’m arguing with @JeffreySarnoff about @JeffreySarnoff’s requirements
Sorry, then I misunderstood. Asking for his “blessings” looked like you wanted his approval for something.
---
### Author:  [@yakir12](https://discourse.julialang.org/u/yakir12)
#### Post date: [September 15, 2017, 11:41am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/19 "2017-09-15T11:41:35Z")
I did. He is of the opinion (if I got him right) that such functionality would be some how bad. I wanted to know how bad. But now I know, it’s probably not _that_ bad.
I’m always afraid that I missed some important reason to do/not do something new. That’s why I ask first here.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [September 15, 2017, 11:55am UTC](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864/20 "2017-09-15T11:55:55Z")
> Float64 values represent integers up to 2^53 exactly. The idea that integer operations incur roundoff errors in floating-point arithmetic is a myth.
We are talking about two different things.
My preference comes from a desire to make the unexpected unlikely. Once one allows floating-point operands, it is difficult to assure that their use will be limited to floating-point conversions of integer values.
[Next page](https://discourse.julialang.org/t/why-do-time-quantities-have-to-be-integers/5864.md?page=2)