Ability to obtain the system's UTC offset

[jhpratt]

Feature

Ability to fetch the system's UTC offset via an internal syscall.

Implementation

The time crate has an implementation allowing for obtaining the offset for Windows, MacOS, Linux, and Solaris (plus cargo_web support). This could likely be used as a starting point.

Alternatives

There really aren't any, given that this is inherently a system API.

---

I'm happy to answer any questions you may have!

[sunfishcode]

This is cool, and I do indeed have questions! :-)

Is a single UTC offset value sufficient to implement a conversion from a nanoseconds-since-the-epoch value into the local time? Is daylight savings time implicitly folded in, taking into account whether daylight savings time was in effect at the specified time? Are leap seconds implicitly folded in?

The code you linked to uses OffsetDateTime, which includes a PrimitiveDateTIme, which includes a date, with year and day index fields, and a time, with hour, minute, second, and nanosecond fields. In a system-API take on this, would it be reasonable to replace all this with just a nanoseconds-since-the-epoch value?

[jhpratt]

The UTC offset is at a particular moment in time. While the OffsetDateTime stores human-length values, it is possible to construct those from the Unix epoch (see impl From<SystemTime> for OffsetDateTime, for example). At least in my case, I can also directly calculate the Unix timestamp from an OffsetDateTime.

It would certainly be reasonable to replace that with a nanoseconds-since-epoch value, whatever that epoch may be. Both Windows and Unix machines expect a value in seconds, though the epoch varies.

DST is folded in to the offset returned. So for New York, it would currently return -5, while next week it'll return -4, as DST starts (note that OS's actually return the value in seconds, due to non-hourly offsets). There are separate APIs for getting DST offset which varies by OS. For Unix-like systems, it amounts to a field on the tm struct. Windows, I'd have to check.

As far as I'm aware, no operating system actually handles leap seconds. If you're using nanoseconds since an epoch, I think it would be best to follow the Unix timestamp's precedent of outright ignoring leap seconds (allowing for duplicate values, essentially).

[jhpratt]

Actually, this should probably go under WebAssembly/WASI, no? Unless there's already something in the wasi standard to this effect.

[sunfishcode]

Yeah, this should go under WASI; would you mind opening a new issue there?

Our current clock APIs are using nanoseconds since the epoch, since it's a convenient way to have a single API that serves multiple purposes, although that can evolve if needed.

Note that I previously opened WebAssembly/WASI#167, though I think a new issue to discuss time zone information specifically would be good. Also note that it isn't necessarily a requirement that we completely implement the POSIX TZ variable; in fact, it looks pretty complex. A simple UTC-offset API is appealing in that it seems like it might provide the basic functionality we actually need in a much simpler way.

[bjorn3]

I think this should be closed in favor of WebAssembly/WASI#239.

[peterhuene]

Agreed this belongs in the WASI repo. Thanks for opening this issue @jhpratt!