# Inconsistent behaviour of Int/Date conversion

**URL:** <https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917>\
**Category:** General Usage\
**Created:** [March 28, 2017, 6:47am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917 "2017-03-28T06:47:47Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 6:47am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/1 "2017-03-28T06:47:47Z")

</div>

Converting from Integers to Dates interprets the relationship differently than converting Dates to Integers. I would assume it to be symmetric. When converting Int → Date, the integer value 1 is interpreted as 1 year. When converting Date → Int, one day is interpreted as the integer value 1.

```julia
Int(Date(4)) # 1096

```

Is there a good reason for this behaviour? It has already given me a few (extra) grey hairs.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [March 28, 2017, 9:20am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/2 "2017-03-28T09:20:33Z")

</div>

With `Date(4)` you are calling the `Date(4, m=1, d=1)` constructor. Try

```julia
convert(Int, convert(Date, 4))

```

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 9:23am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/3 "2017-03-28T09:23:04Z")

</div>

That explains it - but still, shouldn’t `Date(4) == convert(Date, 4)`?

---

<div class="post-metadata">

**Author:** ![andyferris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andyferris/32/235_2.png) [@andyferris](https://discourse.julialang.org/u/andyferris)\
**Post date:** [March 28, 2017, 9:32am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/4 "2017-03-28T09:32:22Z")

</div>

If this were always true, then there wouldn’t be much utility to having `convert` at all.

Think of `Vector{Int}(10)` vs `convert(Vector{Int}, 10)`. What should the latter do?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [March 28, 2017, 9:35am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/5 "2017-03-28T09:35:34Z")

</div>

AFAICT the convention is to use `T(...)` for various constructors, and `convert(T, ...)` for conversion. The two may coincide, but they don’t need to. I agree that this generates unfortunate expectations, since many conversions have the `T(...)` syntax.

Should single-argument constructors enforce `T(x) == convert(T, x)`? I don’t have a strong opinion on this, but it could avoid some hard to find bugs.

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 9:38am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/6 "2017-03-28T09:38:13Z")

</div>

No I agree with that, of course. I was talking about this specific case or similar cases - exactly because of some hard-to-find bugs. I became aware of it because it caused `bar_width` on Plots.plot to fail when TimeTypes were used on the X axis (cf [https://github.com/JuliaPlots/Plots.jl/issues/748](https://github.com/JuliaPlots/Plots.jl/issues/748))

---

<div class="post-metadata">

**Author:** ![andyferris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/andyferris/32/235_2.png) [@andyferris](https://discourse.julialang.org/u/andyferris)\
**Post date:** [March 28, 2017, 9:47am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/7 "2017-03-28T09:47:25Z")

</div>

Yeah, it might be considered bad style to have both methods defined with similar signatures but different behaviour, I dunno. Sometimes it is challenging to avoid, especially if both behaviours are useful.

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 9:52am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/8 "2017-03-28T09:52:58Z")

</div>

Yes I guess that is really my key question here - are both behaviours most useful as they are for some specific reason I haven’t thought of - or is this an unintentional design quirk?

---

<div class="post-metadata">

**Author:** ![pint](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pint/32/125_2.png) [@pint](https://discourse.julialang.org/u/pint)\
**Post date:** [March 28, 2017, 11:15am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/9 "2017-03-28T11:15:32Z")

</div>

```julia
Date(::Int)
Int(::Date)

```

i honestly don’t see what any of these mean intuitively. you can only make sense of these after consulting the documentation. therefore i don’t see any problem with how they behave, no matter what that behavior is. the principle of least surprise does not apply to a situation in which every behavior is equally surprising.

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 11:19am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/10 "2017-03-28T11:19:52Z")

</div>

Well, thanks for your input to the discussion.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [March 28, 2017, 11:23am UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/11 "2017-03-28T11:23:55Z")

</div>

I guess in general both behaviours can be useful (see the example of @andyferris with `Vector{Int}` above), but since the latest iterations of the manual seem to promote `T(...)` for conversion (eg for `Int`, `Float64`), I agree that this can be very confusing.

---

<div class="post-metadata">

**Author:** ![fengyang.wang](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fengyang.wang/32/104_2.png) [@fengyang.wang](https://discourse.julialang.org/u/fengyang.wang)\
**Post date:** [March 28, 2017, 12:56pm UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/12 "2017-03-28T12:56:45Z")

</div>

This conversion method is actually dimensionally incorrect and shouldn’t exist. Check if it has been deprecated on v0.6?

---

<div class="post-metadata">

**Author:** ![mkborregaard](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkborregaard/32/556_2.png) [@mkborregaard](https://discourse.julialang.org/u/mkborregaard)\
**Post date:** [March 28, 2017, 1:05pm UTC](https://discourse.julialang.org/t/inconsistent-behaviour-of-int-date-conversion/2917/13 "2017-03-28T13:05:04Z")

</div>

Interesting, in fact it is! In 0.6 you need to use `Dates.value(Date(4)) #also 1096`.