Open oxinabox opened 4 years ago
I'm not sure about adding this as Date + Time
already exists.
I suggest that we should accept all the common constructors for
DateTime
.
Could you define what you mean by "common"? I wouldn't consider the DateTime(dt::Date, t::Time)
constructor to be used very often and there are several other DateTime
constructors I wouldn't want to introduce.
Alternatively we could stop accepting anything other than a
DateTime
to give that argument
Dropping the ZonedDateTime(y, m, d, ...)
constructor would be a major inconvenience with no upside from what I can see.
Could you define what you mean by "common"? I wouldn't consider the DateTime(dt::Date, t::Time) constructor to be used very often and there are several other DateTime constructors I wouldn't want to introduce.
Common i was thinking as: all the ones in Dates
stdlib (as opposed to ones defined in packages/other standard libraries).
Though I admit some of those are annoyingly obsure/weird.
But just having all of them means that ZonedDateTime
is a almost drop in replacement for DateTime
.
I don't feel particularly strongly about this.
I expected the ZonedDateTime(::Date, ::Time, ::TimeZone)
to work,
i thinki in part becuase of the name,
It is a Zoned Date Time
and I gave it a [Time]Zone
a Date
, and a Time
Right now we accept:
ZonedDateTime(::Date. timezone)
, andZonedDateTime(::DateTime, timezone)
I suggest that we should accept all the common constructors for
DateTime
. Which we can probably do by slurping up arguements and just passing all but the last 1 or two onwards. Alternatively we could stop accepting anything other than aDateTime
to give that argumentExample, the following works:
But this does not: