A little backtracking here. I met Brian Terlson not too long after moving up to Redmond Washington to work for Microsoft. Brian is Microsoft’s representative to TC39, and the editor of the ECMA262 specification.
In this conversation, Brendan gave us some great history on the current
We all decided it was time for a fix and Matt, Brian, and I sat down to work.
In our first meeting, we identified the basic problems with the current
Here they are, in order of relative disgust:
- No support for time zones other than the user’s local time and UTC
- Parser behavior so unreliable it is unusable
- Date object is mutable
- DST behavior is unpredictable
- Computation APIs are unwieldy
- No support for non-Gregorian calendars
Some of the issues mentioned are fixable in the current implementation of date. The lack of time zone support could be mitigated by adding a new factory function to date – something like:
var zonedDate = Date.inZone(zoneIdentifier, dateString);
This technique could probably also be used to support non-Gregorian calendars:
var calendarDate = Date.withCalendar('Hijri', dateString);
In that same vein, we could add APIs to Date to make computations easier. Right now, for instance, there is no way to add or subtract time – one instead has to perform a get/set behavior. To add one week to a date looks something like this:
var myDate = new Date(); myDate.setDate(myDate.getDate() + 7);
It wouldn’t be that big of a deal though, to spec something like an
addDays() method, to make this a little nicer:
var myDate = new Date(); myDate.addDays(7);
The unpredictable DST behavior is another thing that can be fixed, and actually constitutes a bug in the current ECMA262 spec. This bug will be fixed in ECMAScript 2018 by this pull request. I’m planning on a later post to discuss the details of this change, and how “bugs” in the ECMA262 spec are handled.
Web Reality and Web Compatibility
Now we can see that lots of issues with date are fixable. However, we are left with two things on our list that aren’t: mutability and parsing. The reasons that these things can’t be fixed relates to two concepts that TC39 has to deal with a lot –
web compatibility and
web reality. These are the single most difficult things that TC39 has to reckon with, and I’ll tackle them in my next post.