Repository: time-rs/time

Issue #203: Implement function returning the local UTC offset
Created: 2020-01-18T22:25:22Z
As was previously possible in time 0.1 and as requested by multiple people in #197, I would like to add a function allowing the user to obtain their local UTC offset. This information would necessarily come from the operating system.
I do not have sufficient experience with C, let alone interaction with system APIs, so I am requesting this be implemented by those that know better than myself. libc and winapi should suffice as conditional dependencies to cover Linux, MacOS, and Windows. Support for Redox would be nice, but is not essential.
When implementing, the following signature should be used.
impl UtcOffset {
    fn local() -> Self;
}
I can put together docs and tests; it's the implementation itself where assistance is needed. The relevant file is src/utc_offset.rs. Replacing #![forbid(unsafe)] with #![deny(unsafe)] and #[allow]ing the relevant bits is, of course, allowed in this situation.
If you're interested, please leave a comment!

Duplicate issue #197: How does one upgrade from time 0.1 to time 0.2?
Created: 2019-12-20T23:19:18Z
Version 0.1 of the time crate provided a pretty bare-bones API, but it made it easy to create a generic time structure that didn't care if the wrapped time was in UTC, local time, or something else. This was due to the result being a Tm struct, instead of a different type based on whether you were using local time or UTC.
Version 0.2 seems pretty different from this approach, which on first sight seems to make it difficult to migrate from version 0.1. This is best illustrated with some actual code, which can be found here: https://gitlab.com/inko-lang/inko/blob/f668bbe2580aa6f2e12f3bb41eafe252efd3ed7b/vm/src/date_time.rs
The DateTime struct in this file is meant as a very basic type to store the current time, either using the local timezone or UTC. This type is mostly used as an intermediate type to convert the raw Tm struct into a number. Since this project is a VM and language, we don't need more complex types, as the language has its own time library implementation (built around timestamps), which can be found here: https://gitlab.com/inko-lang/inko/blob/f668bbe2580aa6f2e12f3bb41eafe252efd3ed7b/runtime/src/std/time.inko. The DateTime type is also used for some filesystem operations, but those too are all converted to just numbers.
Looking at 0.2 of the time crate, it seems to only support times using UTC as the timezone, with seemingly no support for local time. We could use Rust's SystemTime type for local time, but there does not appear to be a way of converting this to just a Unix timestamp. Similarly, time's own Time type also does not appear to support obtaining the number of seconds since the Unix epoch. All of this looks like it will make it difficult to upgrade from 0.1, unless I am missing something.
Specifically, I am interested in learning more about what one could best do to replace the following APIs that were provided by time 0.1:

time::now()
time::now_utc()
time::at()
Tm::tm_isdst, this was used to check if DST is active or not on the local clock
Tm::to_timespec(), this was used to construct a Unix timestamp in seconds

Closing comment (2020-01-29T16:31:56Z): Pretty much the only reason this issue was open was due to the ability to have local offsets, which is being tracked in #203. Everything else should be sufficiently explained by various documentation.