This means that two different computers might output a different value for the same date object. In any of these cases, the resulting date is relative to the timezone of your computer. Thanks for believing I can do this, and giving me the resources to move forward.New Date( 2018, 6) //Sun 00:00:00 GMT+0200 (Central European Summer Time) It wouldn’t be possible without the joint help of the JS Foundation, who I represent at TC39, and my division, Microsoft Site Reliability Engineering, which is allowing me to put work time and energy into improving technology. This is a project driven from a passion for better JavaScript, and the OSS community. These are the single most difficult things that TC39 has to reckon with, and I’ll tackle them in my next post.Īn Aside: Standards committees are not a part of my regular job description as a SRE for Azure. 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. However, we are left with two things on our list that aren’t: mutability and parsing. Now we can see that lots of issues with date are fixable. I’m planning on a later post to discuss the details of this change, and how “bugs” in the ECMA262 spec are handled. This bug will be fixed in ECMAScript 2018 by this pull request. The unpredictable DST behavior is another thing that can be fixed, and actually constitutes a bug in the current ECMA262 spec. It wouldn’t be that big of a deal though, to spec something like an addDays() method, to make this a little nicer: To add one week to a date looks something like this: Right now, for instance, there is no way to add or subtract time – one instead has to perform a get/set behavior. In that same vein, we could add APIs to Date to make computations easier. Var calendarDate = Date.withCalendar('Hijri', dateString) This technique could probably also be used to support non-Gregorian calendars: Var zonedDate = Date.inZone(zoneIdentifier, dateString) The lack of time zone support could be mitigated by adding a new factory function to date – something like: Some of the issues mentioned are fixable in the current implementation of date. Parser behavior so unreliable it is unusable.No support for time zones other than the user’s local time and UTC.Here they are, in order of relative disgust: In our first meeting, we identified the basic problems with the current Date implementation. We all decided it was time for a fix and Matt, Brian, and I sat down to work. Yet we’re still living with this API 20 years later in the JavaScript programming language. In fact, basically all of it’s methods were deprecated and replaced in the Java 1.1 release in 1997. This implementation was frankly terrible. Brendan, under orders to “make it like Java” copied the date object from the existing, infant, date implementation. That said, it’s a complex problem domain and there was a short timeline.
Date handling is a fundamental part of almost all programming languages, and JavaScript had to have it. It is now common knowledge that in 1995 Brendan was given only 10 days to write the JavaScript language and get it into Netscape. In this conversation, Brendan gave us some great history on the current Date object in JavaScript. I found Brian as part of a twitter conversation between me, Brendan Eich, and Moment.js co-maintainer, and fellow Microsoft employee Matt Johnson about how bad the Date handling in JavaScript is. Brian is Microsoft’s representative to TC39, and the editor of the ECMA262 specification. I met Brian Terlson not too long after moving up to Redmond Washington to work for Microsoft. That said, I’m happy to report that I’m back with stories about a big project – fixing the date handing in the JavaScript programming language itself! HistoryĪ little backtracking here. I’ve been off the blog for a while, which has to do with a lot of things going on in my life.
0 kommentar(er)
