Consider splitting DateTime into a Date and Time type

[yorickpeterse]

The type SystemTime, which is being renamed to DateTime as part of https://gitlab.com/inko-lang/inko/-/merge_requests/120, currently stores all its data (years, month, etc) as separate fields. In https://gitlab.com/inko-lang/inko/-/merge_requests/120 I'm also strongly considering removing support for default arguments. This makes constructing a DateTime a bit more tricky when you only want to specify a subset of the data. For example, if you want to create a DateTime for 1980-01-01 00:00:00 you'd have to write this:

DateTime.new(year: 1980, month: 1, day: 1, hour: 0, minute: 0, second: 0, sub_second: 0.0, utc_offset: 0)

Adding all sorts of static methods to this type leads to a clunky API. Instead, the following is much nicer:

let date = Date.new(year: 1980, month: 1, day: 1)
let time = Time.midnight

DateTime.new(date, time)

Another benefit is that we now have dedicated date and time types that only operate on a date or time; instead of both.

[yorickpeterse]

In addition to this split, I think we need support for different time zones, and perhaps TZ DB parsing. This way the VM only needs to support producing timestamps in UTC. That in turn would allow us to work around the time-rs crate not supporting local offsets (time-rs/time#293).

In short, I want the standard library date/time code to be good enough so we don't need third-party libraries like JodaTime in Java.

[yorickpeterse]

chronotope/chrono#677 chrono should now support parsing timezone files without relying on localtime_r.

[yorickpeterse]

The time-rs dependency is removed as part of https://gitlab.com/inko-lang/inko/-/commit/d07e3543a47c6312fc5883dcd9d138329a2e5aa7, and we now just use the underlying libc/Windows APIs directly.

[yorickpeterse]

Two resources worth looking into:

• https://www.joda.org/joda-time/
• https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html (replaces Joda-Time)