Support retrieval of the host system time zone as icu_timezone::CustomTimeZone

[hsivonen]

Instantiating an icu_timezone::CustomTimeZone that represents the current time zone of the host system is an operation that is likely to be commonly needed by apps while requiring special expertise (as well as access to alias data) to implement correctly. Therefore, it would be natural for ICU4X to provide this operation.

AFAICT, ICU4C provides this but both Chromium and Firefox work around https://unicode-org.atlassian.net/browse/ICU-13694 , so ICU4X should be written not to need a workaround.

(Since this operation is inherently both operating system-dependent and operating system-specific, it obviously can't be an inseparable part of icu_timezone but either needs to be omissible using cargo features or needs to be in its own crate so that icu_timezone continues to work in a mere core+alloc context.)

[robertbastian]

We have std features on all crates, so it can be conditional on that.

I'm not sure this method should be tz-only though. Maybe we should have get_system_locale, that encapsulates all system information (language, region, hour format, time zone, etc.). This allows us to keep the system interface as small as possible, and makes it easy to use locales from other source instead. If we had special system constructors on higher levels (like for tz, datetime, etc.), I think it would get messy.

[hsivonen]

Is our Locale object sufficient for the data? Is BCP47 -u-tz robust enough to capture possible situations with host time zone? AFAICT, -u-tz takes a time zone id and cannot fall back to UTC offset.

In general, though, of the system information, BCP47 does not encapsulate the short date format that is user-settable on Microsoft and Apple systems. It's unclear to me if actual use cases go beyond overriding the locale default to yyyy-MM-dd. That is, it's unclear to me if a boolean flag (to force yyyy-MM-dd) as a -u- extension would sufficiently cover use cases.

[sffc]

@zbraniecki for discussion of retrieval of preferences from the OS

[sffc]

Discuss with:

• @sffc
• @zbraniecki
• @nordzilla
• @Manishearth
• @leftmostcat

Optional:

• @hsivonen