tc39 / proposal-built-in-modules

BSD 2-Clause "Simplified" License
892 stars 25 forks source link

Better time zones #25

Closed StoneCypher closed 5 years ago

StoneCypher commented 5 years ago

The current timezone mechanism afforded is occasionally reparably ambiguous.

With respect to that the problem is genuinely difficult, based on that the timezone tables vary over time, and the operating system generally does not afford to an application its own tables, making the job of verifying its worldview problematic, and with an appreciation for that Unix Time Solves Nearly All Things™, a few problems remain which need system support for appropriate resolution.

However, there are times at which I need to be able to compute a time on a different date in the local timezone, or other various tomfoolery. This isn't actually safely possible. Timezones switch on different dates, or by different distances, meaning the same computed delta could meaningfully refer to several incompatible timezones.

In my opinion, this can be repaired through simple extension. My steps to repair the timezone API would include:

  1. What is the current local timezone
    1. With daylight savings
    2. Without
  2. Are we currently in daylight savings
    1. When does that next change
    2. When did that last change
    3. Will we be in daylight savings at unixtime X
  3. What is the local current GMT delta
    1. What was the local GMT delta at unixtime X

It would possibly be equally/more useful to be able to create Date objects in specific timezones. At that point, merely adding the "is this datetime in DST" to the existing Date API would cover all of the above steps.

ljharb commented 5 years ago

See https://github.com/tc39/proposal-temporal ; specifically, https://github.com/tc39/proposal-temporal/issues/103

StoneCypher commented 5 years ago

Oh, fantastic. My old one was long since gone and I thought I was the only one that cared