5 ms·

From TFA: > When JavaScript was created in 1995, the Date object was copied from Java's early, flawed java.util.Date implementation. Java replaced this impleme

From TFA: > When JavaScript was created in 1995, the Date object was copied from Java's early, flawed java.util.Date implementation. Java replaced this implementation in 1997, but JavaScript is stuck with the same API for almost 30 years, despite known problems. I'm not a JavaScript or web developer, and I was surprised by the above. Can anyone comment on why the language was stuck with an inadequate api for so long? What are the forces at work here?

baq 2y ago
First rule of being a platform: Do Not Break Existing Code.
- spiffyk 2y ago
  Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.
- Cthulhu_ 2y ago
  That's fair, but they didn't need to - just make a new Date library and deprecate the old one.
mrbluecoat 2y ago
I've been a JavaScript developer since the nineties and I too have been puzzled about this very thing. Everyone has known Date has been broken for a very long time and a plethora of pollyfills and datetime libraries have sprung up to band-aid the situation but nothing ever got close to being resolved as major ECMAscript versions were released over the years. I guess if it takes 270 pages for MDN to explain it, it's a rocket science problem that's well over my head.
rakatata 2y ago
I think they thought they could get away with a hotfix like Intl.DateTimeFormat()
- deleted 2y ago
  [deleted]
Secretmapper 2y ago
Javascript, for the longest time, was a _slow_ moving target - web browsers themselves had cross browser issues where API X might work on browser A but not on browser B. There were so many bigger issues like that I think that made this not a high priority in the grand scheme of things. I think a good example of this is jQuery - while jQuery is a good tool, a huge part of its usage was the quirks between browsers. Selectors and the class of problems jQuery solved had more immediate impact to web applications, so fixing and taking from it became a more immediate concern. JS API -> moment/date-fn/luxon -> Temporal has the same kind of trajectory. Not that those libraries will now be immediately 'bad' mind you - just that the base API is more sane.
- phire 2y ago
  And for the longest time, nobody even considered javascript to be a serious tool; It was rare for anyone to write more than a hundred lines of javascript. I remember when google introduced gmail in 2004. Suddenly google had done full single-page application in javascript, proving that not only was it possible, but that the resulting user-experience was awesome. At the time, there were no javascript frameworks. Jquery (if you can even call it a framework) wasn't created until 2006. I don't think there were even helper libraries. I mostly remember javascript from dynamicdrive.com, where you would go to find quick snippets of "Dynamic HTML" to copy/paste into your html. Sometimes there were useful things like roll-over menus, but I remember many of them being silly toys, like sparkles that would follow your mouse around the screen, or snow which would slowly cover the page.
  - agos 2y ago
    excellent point. it took 6 years (!) for Backbone.js, arguably the first Javascript framework, to come out... and the same year AngularJS.
DanielHB 2y ago
Well browser standards were pretty much gimped by microsoft during the IE5/IE6 era, so from 1998 until around 2010 there was no progress on standards and Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share. From 2010 until about 2020 I would say the standard committee took hold and they have been quite busy with other things. Since JS is a language defined by committee it can take quite some time for people to agree on APIs which is a subjective topic. The last thing the standards body want is to introduce an API and then deprecate it in favor of another API slightly later.
- boplicity 2y ago
  > Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share. Boy, it's a different company doing this now, but this is definitely still something that is happening, especially in mobile.
  - DanielHB 2y ago
    Not to the same level as back then, the closest thing would be Apple refusing to implement good PWA integration and Web Push Notifications (forcing people to use Apple Push Notifications which only works in Safari). PWAs are still (mostly) supported in Safari, they just don't integrate at the OS level in iOS. Apple is still actively developing Safari and JSC and implementing standards, Microsoft basically COMPLETELY FROZE browser improvements for 10+ years. Worse even, they pushed proprietary Microsoft-only solutions to try to lock-in people.
- harrall 2y ago
  Microsoft was MASSIVELY trying to make web applications a thing. They introduced HTML Applications[1] in 1999 (e.g. Electron). In 2001, they added the JavaScript features that let us have Gmail and Google Maps (XMLHttpRequest). They let you rebuild your Windows desktop or any folder as a HTML in Windows 2000/ME. They created a ton of APIs from web components[2] to CSS effects[3] in 1998. However, when Netscape died, Microsoft did a 180 and went from the leader in promoting the web to the absolute worst obstruction. It seemed like they completely de-funded their IE development team. [1] https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application [2] https://en.wikipedia.org/wiki/HTML_Components https://en.wikipedia.org/wiki/HTML_Components [3] https://learn.microsoft.com/en-us/previous-versions/ms530752(v=vs.85) https://learn.microsoft.com/en-us/previous-versions/ms530752... (previously was just filter:)
mrkeen 2y ago
> Java replaced this implementation in 1997 If that date's correct, they replaced it with another flawed implementation. The 'good' one came much later: https://jcp.org/en/jsr/detail?id=310 https://jcp.org/en/jsr/detail?id=310 > What are the forces at work here? I feel like I'm always simultaneously engaged in about 5 HN threads at a time, advocating for some combination of immutability, type-safety, and/or no-nulls. It's basically all I do. By and large, people simply aren't into it. "Because the world is shared and mutable" is a pretty common rebuttal: 4 hours ago: https://news.ycombinator.com/item?id=42876487 https://news.ycombinator.com/item?id=42876487 2 days ago: https://news.ycombinator.com/item?id=42850569 https://news.ycombinator.com/item?id=42850569
- papercrane 2y ago
  1997 would be JDK 1.1, which introduced the java.util.Calendar/GregorianCalendar classes. The Calendar API was an improvement in some use cases over Date, but it's biggest flaw was mutability. The current API is based on JodaTime and is very similar to Temporal.
- agos 2y ago
  and yet on threads about Elixir there seems a lot of people who care – rightly so, immutability it's great and Elixir makes the best out of it. Don't give up the good fight!
stevoski 2y ago
Going back even further in time, Java.util.Date was was heavily inspired by a C library. That’s the origin of getMonth() in Java (and therefore in JS) returning a value from 0-11 and not 1-12 as many coders initially expect. What was the origin for this peculiarity in C? That I don’t know, but I’m curious to find out if anyone knows.
- wanderingstan 2y ago
  Just spitballing, but in C it was always the convention to use zero-based indexing. Probably because you were often adding these indexes to pointers (literal memory addresses) to index into an array, so you needed a zero to index into the first slot of the array.
  - 8n4vidtmkvmk 2y ago
    What I don't get is why the day of the month doesn't also start at 0?
- andyjohnson0 2y ago
  C uses zero-based array indexing. A C array variable is a pointer to its first element, and an element index is just an offset from that. Element 0 is at start + 0, element 1 is at start + (1 * element size) etc. Which why the fields of the 'tm' structure [1] (used to represent dates and times) are zero based§. Makes it easy to index into eg an array of day names using tm_wday. I guess at one time Java.util.Date was a leaky abstraction layer on-top of such an api. § Except for the tm_mday element, which curiously is 1-based. I've always assumed that this is because it is unlikely to be used as an array index. A long time ago I'm ashamed to admit that I used tm_mday == 0 as a quick check for an invalid tm value. [1] https://en.cppreference.com/w/c/chrono/tm https://en.cppreference.com/w/c/chrono/tm

baq 2y ago

First rule of being a platform: Do Not Break Existing Code.

spiffyk 2y ago
Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.
Cthulhu_ 2y ago
That's fair, but they didn't need to - just make a new Date library and deprecate the old one.

mrbluecoat 2y ago

I've been a JavaScript developer since the nineties and I too have been puzzled about this very thing. Everyone has known Date has been broken for a very long time and a plethora of pollyfills and datetime libraries have sprung up to band-aid the situation but nothing ever got close to being resolved as major ECMAscript versions were released over the years. I guess if it takes 270 pages for MDN to explain it, it's a rocket science problem that's well over my head.

rakatata 2y ago

I think they thought they could get away with a hotfix like Intl.DateTimeFormat()

deleted 2y ago
[deleted]

Secretmapper 2y ago

Javascript, for the longest time, was a _slow_ moving target - web browsers themselves had cross browser issues where API X might work on browser A but not on browser B. There were so many bigger issues like that I think that made this not a high priority in the grand scheme of things. I think a good example of this is jQuery - while jQuery is a good tool, a huge part of its usage was the quirks between browsers. Selectors and the class of problems jQuery solved had more immediate impact to web applications, so fixing and taking from it became a more immediate concern. JS API -> moment/date-fn/luxon -> Temporal has the same kind of trajectory. Not that those libraries will now be immediately 'bad' mind you - just that the base API is more sane.

phire 2y ago
And for the longest time, nobody even considered javascript to be a serious tool; It was rare for anyone to write more than a hundred lines of javascript. I remember when google introduced gmail in 2004. Suddenly google had done full single-page application in javascript, proving that not only was it possible, but that the resulting user-experience was awesome. At the time, there were no javascript frameworks. Jquery (if you can even call it a framework) wasn't created until 2006. I don't think there were even helper libraries. I mostly remember javascript from dynamicdrive.com, where you would go to find quick snippets of "Dynamic HTML" to copy/paste into your html. Sometimes there were useful things like roll-over menus, but I remember many of them being silly toys, like sparkles that would follow your mouse around the screen, or snow which would slowly cover the page.
- agos 2y ago
  excellent point. it took 6 years (!) for Backbone.js, arguably the first Javascript framework, to come out... and the same year AngularJS.

DanielHB 2y ago

Well browser standards were pretty much gimped by microsoft during the IE5/IE6 era, so from 1998 until around 2010 there was no progress on standards and Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share. From 2010 until about 2020 I would say the standard committee took hold and they have been quite busy with other things. Since JS is a language defined by committee it can take quite some time for people to agree on APIs which is a subjective topic. The last thing the standards body want is to introduce an API and then deprecate it in favor of another API slightly later.

boplicity 2y ago
> Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share. Boy, it's a different company doing this now, but this is definitely still something that is happening, especially in mobile.
- DanielHB 2y ago
  Not to the same level as back then, the closest thing would be Apple refusing to implement good PWA integration and Web Push Notifications (forcing people to use Apple Push Notifications which only works in Safari). PWAs are still (mostly) supported in Safari, they just don't integrate at the OS level in iOS. Apple is still actively developing Safari and JSC and implementing standards, Microsoft basically COMPLETELY FROZE browser improvements for 10+ years. Worse even, they pushed proprietary Microsoft-only solutions to try to lock-in people.
harrall 2y ago
Microsoft was MASSIVELY trying to make web applications a thing. They introduced HTML Applications[1] in 1999 (e.g. Electron). In 2001, they added the JavaScript features that let us have Gmail and Google Maps (XMLHttpRequest). They let you rebuild your Windows desktop or any folder as a HTML in Windows 2000/ME. They created a ton of APIs from web components[2] to CSS effects[3] in 1998. However, when Netscape died, Microsoft did a 180 and went from the leader in promoting the web to the absolute worst obstruction. It seemed like they completely de-funded their IE development team. [1] https://en.wikipedia.org/wiki/HTML_Application https://en.wikipedia.org/wiki/HTML_Application [2] https://en.wikipedia.org/wiki/HTML_Components https://en.wikipedia.org/wiki/HTML_Components [3] https://learn.microsoft.com/en-us/previous-versions/ms530752(v=vs.85) https://learn.microsoft.com/en-us/previous-versions/ms530752... (previously was just filter:)

mrkeen 2y ago

> Java replaced this implementation in 1997 If that date's correct, they replaced it with another flawed implementation. The 'good' one came much later: https://jcp.org/en/jsr/detail?id=310 https://jcp.org/en/jsr/detail?id=310 > What are the forces at work here? I feel like I'm always simultaneously engaged in about 5 HN threads at a time, advocating for some combination of immutability, type-safety, and/or no-nulls. It's basically all I do. By and large, people simply aren't into it. "Because the world is shared and mutable" is a pretty common rebuttal: 4 hours ago: https://news.ycombinator.com/item?id=42876487 https://news.ycombinator.com/item?id=42876487 2 days ago: https://news.ycombinator.com/item?id=42850569 https://news.ycombinator.com/item?id=42850569

papercrane 2y ago
1997 would be JDK 1.1, which introduced the java.util.Calendar/GregorianCalendar classes. The Calendar API was an improvement in some use cases over Date, but it's biggest flaw was mutability. The current API is based on JodaTime and is very similar to Temporal.
agos 2y ago
and yet on threads about Elixir there seems a lot of people who care – rightly so, immutability it's great and Elixir makes the best out of it. Don't give up the good fight!

stevoski 2y ago

Going back even further in time, Java.util.Date was was heavily inspired by a C library. That’s the origin of getMonth() in Java (and therefore in JS) returning a value from 0-11 and not 1-12 as many coders initially expect. What was the origin for this peculiarity in C? That I don’t know, but I’m curious to find out if anyone knows.

wanderingstan 2y ago
Just spitballing, but in C it was always the convention to use zero-based indexing. Probably because you were often adding these indexes to pointers (literal memory addresses) to index into an array, so you needed a zero to index into the first slot of the array.
- 8n4vidtmkvmk 2y ago
  What I don't get is why the day of the month doesn't also start at 0?
andyjohnson0 2y ago
C uses zero-based array indexing. A C array variable is a pointer to its first element, and an element index is just an offset from that. Element 0 is at start + 0, element 1 is at start + (1 * element size) etc. Which why the fields of the 'tm' structure [1] (used to represent dates and times) are zero based§. Makes it easy to index into eg an array of day names using tm_wday. I guess at one time Java.util.Date was a leaky abstraction layer on-top of such an api. § Except for the tm_mday element, which curiously is 1-based. I've always assumed that this is because it is unlikely to be used as an array index. A long time ago I'm ashamed to admit that I used tm_mday == 0 as a quick check for an invalid tm value. [1] https://en.cppreference.com/w/c/chrono/tm https://en.cppreference.com/w/c/chrono/tm