0

The code is: 

var rightNow = new Date();
console.log(rightNow);

In Chrome 66 it returns:

Tue Jun 12 2018 15:36:19 GMT+0530 (IST)

In Chrome 67 it returns:

Tue Jun 12 2018 15:36:43 GMT+0530 (India Standard Time)

Why the difference?

A lot of my code works with the behaviour in chrome 66. Do I need to change all the code?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
Vikas kedia
  • 9
  • 3
  • 1
    That's just a slight change of representation, have you actually noticed any *problems*? – jonrsharpe Jun 12 '18 at 10:13
  • 1
    Yes .. since I sent the value to the server side. On server side I use carbon library of php to understand this date and timezone. Carbon is failing to understand the new format – Vikas kedia Jun 12 '18 at 10:37
  • 1
    Why do you send it as `.toString()`? Send it as an ISO8601-formatted datetime, or a Unix-style timestamp. – jonrsharpe Jun 12 '18 at 10:42
  • The application is being used by people in different timezones. If I just send the timestamp back to the server I will loose the information of what timezone was this topic created at. This change is pretty major in chrome. Why cannot I see this change in chrome 67 releases notes ? – Vikas kedia Jun 12 '18 at 10:51
  • Why would your users care which time zone something happened in? They just care about when it happened, surely; you localise the datetime purely on the client side, the server shouldn't care. – jonrsharpe Jun 12 '18 at 10:53
  • well for historical reasons the client sends the string back to the server. The server parses the string using php's carbon library. Is this historical code now broken? – Vikas kedia Jun 12 '18 at 10:57
  • 1
    Looks like, yes. You should have used a proper standardised format, not whatever representation the browser implementation chose; that's up to the vendor per e.g. https://stackoverflow.com/a/39888177/3001761. – jonrsharpe Jun 12 '18 at 11:03

1 Answers1

1

In general, you should not code for a specific browser, but to the standards. In this case, the standard is ECMAScript (ECMA-262). Section 20.3.4.41 covers Date.prototype.toString(), which refers to the following section describing the internal ToDateString(tv) function, which explains:

Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form.

By "implementation-dependent", it means that the actual string value is not defined by the specification, and can vary from one implementation to another. You are not guaranteed the same result from one browser to the next, or from one version of a browser to the next, or even from one operating system to the next from the same version of the same browser.

By "human-readable form", it means that the value produced is suitable for display to a human being. It makes no guarantees about that value being represented in a manner that can be parsed consistently by computer code.

Thus, if you intend for the string value to be sent to other code, you should not use .toString(). In general, you should prefer an ISO 8601 formatted string for this purpose. Use .toISOString() if you want the result in terms of UTC. Refer to this answer (or use a library) if you want the result in terms of local time including a time zone offset.

As to why things changed between Chrome 66 and Chrome 67 - I don't have the exact details, but I assume Chrome switched from using IANA TZDB abbreviations to using CLDR time zone names, probably through its use of ICU. This is reasonable, and is what many other implementations are doing. There's no requirement it use one set of data or the other though, so don't rely on such things.

Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575