# TimesDates.jl dev for v2
**URL:** https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377
**Category:** Specific Domains
**Tags:** dates, time, internals
**Created:** [March 24, 2022, 10:00am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377 "2022-03-24T10:00:08Z")
**Posts on this page:** 5
**Page:** 3
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [September 13, 2023, 6:40pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/42 "2023-09-13T18:40:12Z")
The fact that durations have time units is not an implementation detail but a part of the interface. It’s nice for the code to track what the units are. You can check whether the magnitude is zero with `iszero` though:
```julia
julia> iszero(Millisecond(0))
true
julia> iszero(Millisecond(1))
false
```
---
### Author:  [@ryofurue](https://discourse.julialang.org/u/ryofurue)
#### Post date: [September 14, 2023, 2:32am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/43 "2023-09-14T02:32:08Z")
> [@jar1](#):
>
> The fact that durations have time units is not an implementation detail
That statement itself is correct. But, the following two statements are totally different:
1. Durations have time units.
2. The smallest duration is 1 millisecond.
You are saying 1. The current implementation _appears to_ expose 2. If you change the internal implementation to include microseconds, what would the output of `(t2 - t1) % Dates.Hour(1)` be?
> [@jar1](#):
>
> part of the interface
That means, perhaps, we would get
```julia
julia> (t2 - t1) % Dates.Hour(1)
123.456 milliseconds
```
if `DateTime` started to resolve microseconds?
If that’s what you mean by that milliseconds is just an interface, not an implementation detail, then I agree with you.
> [@jar1](#):
>
> `julia> iszero(Millisecond(0))`
Okay, that makes perfect sense! Then, I guess this documentation
[https://docs.julialang.org/en/v1/stdlib/Dates/#Durations/Comparisons](https://docs.julialang.org/en/v1/stdlib/Dates/#Durations/Comparisons)
should include `iszero()` in the “Comparisons” section. . . . (I’m not at all familiar with github and am still struggling to set it up for my account, so it would take a lot of time, which I don’t currently have, for me to be able to create a pull request. Sorry.)
My original issue was probably documentation problem or perhaps cultural. When I asked a question about `DateTime` arithmetic here in this forum when I was a total newbie, some people recommended solutions which assumed that the minimal duration step is one millisecond, using the `.value` attribute, if I remember correctly.
In hindsight, they should have recommended dividing by `Millisecond(1)` instead of referring to `.value`. Then nothing would have depended on the implementation detail.
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [September 14, 2023, 3:03am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/44 "2023-09-14T03:03:28Z")
The significance of milliseconds for the DateTime API has been debated recently on here and GitHub.
>
>
> ~~Resolves #50785~~ EDIT: the PR changed over time, see the discussion
>
> This i…s a proposal for fixing the linked issue. The PR consists of two commits.
>
> The first commit just adds a few tests and one sentence to the docs of \`DateTime\`. I think this could be merged.
>
> The second commit changes addition/subtraction of a \`DateTime\` and \`Microsecond\`/\`Nanosecond\`.
> Before:
> \`\`\`julia
> julia\> DateTime(2023, 08, 07) + Microsecond(1) # truncates
> 2023-08-07T00:00:00
>
> julia\> DateTime(2023, 08, 07) + Nanosecond(1) # truncates
> 2023-08-07T00:00:00
>
> julia\> DateTime(2023, 08, 07) + Microsecond(10^3)
> 2023-08-07T00:00:00.001
>
> julia\> DateTime(2023, 08, 07) + Nanosecond(10^6)
> 2023-08-07T00:00:00.001
> \`\`\`
> After:
> \`\`\`julia
> julia\> DateTime(2023, 08, 07) + Microsecond(1) # throws
> ERROR: InexactError: +(Millisecond, 1 microsecond)
>
> julia\> DateTime(2023, 08, 07) + Nanosecond(1) # throws
> ERROR: InexactError: +(Millisecond, 1 nanosecond)
>
> julia\> DateTime(2023, 08, 07) + Microsecond(10^3)
> 2023-08-07T00:00:00.001
>
> julia\> DateTime(2023, 08, 07) + Nanosecond(10^6)
> 2023-08-07T00:00:00.001
> \`\`\`
> The second commit is breaking so I am not sure if it can be merged.
>
> cc @jariji
> [@\`DateTime\` arithmetic on \`Microsecond\` (or smaller) scale](https://discourse.julialang.org/t/datetime-arithmetic-on-microsecond-or-smaller-scale/102949):
>
> There is currently a [PR on the repo](https://github.com/JuliaLang/julia/pull/50816) with very lively discussion about what the following operation should do: using Dates a = now() b = a + Nanosecond(1) (the situation is analogous with Microsecond) Currently, the result is always exactly equal to a, because the DateTime arithmetic implemented in Dates simply truncates the non-DateTime argument to milliseconds (as that is the supported precision of DateTime), and whatever the result is, will be added to DateTime: julia\> using Dates julia\>…
---
### Author:  [@ryofurue](https://discourse.julialang.org/u/ryofurue)
#### Post date: [September 14, 2023, 3:34am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/45 "2023-09-14T03:34:32Z")
By the way,
> [@jar1](#):
>
> `julia> iszero(Millisecond(0))`
during the writing of my initial posting, I thought that even a unitful duration should be able to be compared with zero. We all understand that
> 1 minute ≠ 1 second
but zero is special. All zeros are equal, aren’t they? 0 minutes = 0 seconds = 0 milliseconds.
Even worse
```julia
julia> m = (t2 - t1) % Dates.Hour(1)
0 milliseconds
julia> m == 0
false
```
At least, shouldn’t `m == 0` result in error? This can be a source of silent bugs.
Complex numbers do the right thing:
```julia
julia> a = 3 + 4.2im
3.0 + 4.2im
julia> a < 0
ERROR: MethodError: no method matching isless(::ComplexF64, ::Int64)
```
Are these unit-ed durations part of the `Dates` package? or does the package utilize unit-ed numbers defined elsewhere?
---
### Author:  [@jar1](https://discourse.julialang.org/u/jar1)
#### Post date: [September 14, 2023, 3:50am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/46 "2023-09-14T03:50:59Z")
> [@ryofurue](#):
>
> At least, shouldn’t `m == 0` result in error? This can be a source of silent bugs.
Yes
>
>
> I often make mistakes by using \`==\` between two objects that I shouldn't be comp…aring, such as comparing a number to an array of numbers or comparing a string to a character. The \`==\` comparison evaluates to \`false\`, but it wasn't the comparison I meant to make. For example,
>
> \`\`\`jl
> a = \[1,2,3\]
> b = 5
>
>
> if a == b; # evaluates to false
> \`\`\`
>
> I wish there were an equality-checking operator that would give an error for incompatible types, like in the example above. I'm not sure if the right implementation would be
>
> \- check if they have exactly the same type
> \- check some \`\<:\` subtyping relationship
> \- check if they can \`convert\` into each other's types
> \- check if they can \`promote\` into a shared type
>
> or something else, or multiple different operators for different purposes. There are plenty of equals-like operators in unicode (eg ≟, ≐). Regardless, the current situation where my mistakes result in silent \`false\`s causes me problems too often for comfort; I would much rather get an explicit error that I can correct.
>
> What would be a good solution here?
[Previous page](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377.md?page=2)