chrono
chrono copied to clipboard
`DateTime::naive_local` is ambiguous
Consider this snippet:
let t = Utc::now();
let a = t.naive_utc();
let b = t.naive_local();
a
and b
are always equal, while one would expect a
to be UTC and b
to be the users local time zone. The reason is that local
here refers to the time zone of the date time object, but one could think that it means the users local time zone.
I think a reasonable name would be just naive
instead of naive_local
. If the user is unsure about the time zone, this name forces him to look it up in the documentation. An alternative would be to force the user to specify a time zone explicitly and give naive_local
a signature like this:
fn naive(&self, tz: &impl TimeZone) -> NaiveDateTime;
I think the same applies to
-
Date::naive_local
-
TimeZone::from_local_datetime
-
TimeZone::from_local_date
-
TimeZone::offset_from_local_datetime
-
TimeZone::offset_from_local_date
#253 is related but I created a new issue because #253 is about the documentation.
Somewhat related: I think that Date::naive_utc
should not exist. The user should have to specify a time to get anything other than the NaiveDate
in the time zone of the Date
object, because anything else can't be known.
I also found the behavior and naming of naive_local and naive_utc to be very confusing. naive_local does NOT give you a naive date in the local timezone, whereas naive_utc DOES give you a naive date in UTC.
Definitely need to change the name to not overload the term "local" which is already used for the Local struct that implements TimeZone.
NaiveDateTime is just a datetime without a timezone.
Should t.naive_local() convert t to local time of the users timezone and then strip away the timezone information? Where as t.naive_utc() should strip away the timezone info?
I found another issue that's related to this https://github.com/chronotope/chrono/issues/296
One of the contributors said they were tempted to remove these functions, I would agree. There should be a .to_naive() method that just returns a NaiveDateTime Object by striping the tz info, the programmer would be responsible for converting to the right tz before calling that method. I think a more minimal public interface will improve this library