Open sffc opened 1 month ago
I can take a look at this if no one has started it yet.
I wrote one function in https://github.com/unicode-org/icu4x/pull/5202. Unfortunately it can't be infallible because the UTCOffsetRecord
fields are public, so they could represent an out-of-bounds offset.
Ok, in #5260 I added ixdtf parsing functions for Date, Time, and DateTime.
We should also add them to:
Similar to how the Date and DateTime AnyCalendar impls require #[feature = "compiled_data"]
, I think these ones should also have that requirement, and they should use compiled data to convert the IANA to BCP-47 time zone ID and look up the metazone. We need to leave the zone variant blank for now since there isn't a way to derive that from the IXDTF string without TZDB.
@nekevss I'm assigning this to you based on https://github.com/unicode-org/icu4x/issues/5201#issuecomment-2215575876.
I noticed that we have
CustomZonedDateTime::try_iso_from_ixdtf_str
DateTime::try_iso_from_str
Why does one have ixdtf
in the name and the other not?
Mainly, GmtOffset
has try_from_str
and from_str
, which is also fairly visible in the docs. Meanwhile, the method for CustomTimeZone
was going to be CustomTimeZone::try_from_str
. Since the format of the input expected by the CustomTimeZone
method (along with CustomZonedDateTime
) are different than GmtOffset::try_from_str
, the thought was to avoid confusion by being explicit in the method name CustomTimeZone::try_from_ixdtf_str
. This naming then was extended to CustomZonedDateTime
for consistency.
I do agree though that the method names being different between CustomZonedDateTime
and DateTime
are not ideal.
If you don't have too much concern about potential confusion between GmtOffset::try_from_str
and CustomTimeZone::try_from_str
, then I'd be fine with updating both to *_from_str
or a half step of keeping CustomTimeZone::try_from_ixdtf_str
and ZonedDateTime::try_iso_from_str
Discussion:
CustomTimeZone::try_from_ixdtf_str("America/Chicago")
?CustomTimeZone::try_from_iana_str
(need to think about name) which takes strings like "America/Chicago" and "-0600" and does the best it can to populate the fields of CustomTimeZoneCustomTimeZone::try_from_ixdtf_str
that has current behaviorCustomTimeZone::try_from_str
that first tries iana
and then ixdtf
try_from_str
CustomZonedDateTime::try_from_str
and then you can just pull the time zone out of it.
A convenience function we should definitely support:
impl From<UTCOffsetRecord> for GmtOffset
Probably there are a few more we should also add.
CC @nekevss