Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NodeJS not applying date locales properly #8500

Closed
wilkyboy opened this issue Sep 12, 2016 · 15 comments
Closed

NodeJS not applying date locales properly #8500

wilkyboy opened this issue Sep 12, 2016 · 15 comments
Labels
i18n-api Issues and PRs related to the i18n implementation.

Comments

@wilkyboy
Copy link

wilkyboy commented Sep 12, 2016

In all three of my environments I was able to reproduce this error:

My production server

  • Version: v6.5.0
  • Platform: Linux 2.srv.wilkynet.uk 4.4.11-x1-64+ deps: update openssl to 1.0.1j #1 SMP Fri May 20 14:04:36 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
  • Subsystem: core js?

My primary development machine

  • Version: v4.4.0
  • Platform: Microsoft Windows [Version 10.0.10586] x64
  • Subsystem: core js?

My secondary development machine

  • Version: v4.3.1
  • Platform: Darwin Ben Wilkinson's MacBook Pro 15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64
  • Subsystem: core js?

I can't get nodejs to properly format a datetime string in the machine locale. On all of these machines the locale is set to British English, and when recreated on each machine, I get the same output, so I'll just post it once.

The expected behaviour is as such with the en-GB locale set:

> new Date().toLocaleString();
'12/09/2016, 18:14:37'
> new Date().toLocaleString('en-GB');
'12/09/2016, 18:15:31'
> new Date().toLocaleString('en-US');
'9/12/2016, 6:15:34 PM'

I get:

> new Date().toLocaleString();
'9/12/2016, 6:14:37 PM'
> new Date().toLocaleString('en-GB');
'9/12/2016, 6:15:31 PM'
> new Date().toLocaleString('en-US');
'9/12/2016, 6:15:34 PM'

However, when tested in the chrome console, I get the following:

new Date().toLocaleString();
"12/09/2016, 18:03:03"
new Date().toLocaleString('en-GB');
"12/09/2016, 18:03:08"
new Date().toLocaleString('en-US');
"9/12/2016, 6:03:11 PM"

What's going on here? Am I doing something wrong, or is there a bug here?

@wilkyboy wilkyboy changed the title NodeJS not applying locales properly NodeJS not applying date locales properly Sep 12, 2016
@mscdex mscdex added v8 engine Issues and PRs related to the V8 dependency. i18n-api Issues and PRs related to the i18n implementation. labels Sep 12, 2016
@mscdex
Copy link
Contributor

mscdex commented Sep 12, 2016

By default --with-intl=small-icu is used to build node, which contains just the en-US locale (@nodejs/intl -- is this correct or does it contain more?). You will need to either build node with --with-intl=full-icu or --with-intl=system-icu if you want to be able to use more locales. The reason node is built with a smaller ICU by default is file size.

@mscdex mscdex removed the v8 engine Issues and PRs related to the V8 dependency. label Sep 12, 2016
@targos
Copy link
Member

targos commented Sep 12, 2016

There is another option that doesn't require a custom build of node. You can install the full-icu module.

@wilkyboy
Copy link
Author

Thank you! At least this is now up somewhere where others can find it.

@cawoodm
Copy link

cawoodm commented Nov 8, 2019

Funny that "JavaScript" or NodeJs can offer a built-in function toLocaleDateString which not only delivers incorrect results (yyyy-M-d is not the format for any de-* locale) but also return a format yyyy-M-d which is incorrect in any locale (yyyy-MM-dd I could understand).

(new Date()).toLocaleDateString('de-CH'); // 2019-11-8 // Wrong

Installing full-icu globally and requiring it does not fix this.

@aprilmintacpineda
Copy link

I experienced this with my colleague while running integration tests on our app, we were using new Date(date).toLocaleDateString('en-AU') and we get different outputs, turns out to be NodeJS Version, he was using NodeJS@12, I was using NodeJS@13

new Date('11/29/2019').toLocaleDateString('en-AU')

NodeJS@12: 11/29/2019 <-- incorrect
NodeJS@13: 29/11/2019 <-- correct

I seek enlightenment.

@GitTom
Copy link

GitTom commented Nov 20, 2019

The official distribution of Node 13 includes 'full icu': the locale database. Without that data Node only supports 'en-US' and will throw for other languages, and silently fall back to 'en-US' for English with other countries. What makes that so insidious is that no other English countries use the US date format and most use the British format which can be ambiguous so you won't even realize it is wrong.

If you have control over your Node invocation (ie. you are not using 3rd party FaaS) then you can add 'full icu' to earlier versions of node via a flag and a data file.

@cawoodm
Copy link

cawoodm commented Nov 22, 2019

I don't understand why localization is "tacked" on to node like this. Surely date formats for 100 or so countries can't be more than a kb or so of additional weight.

@sam-github
Copy link
Contributor

1kb allows about 5 bytes per country in the world.... ICU is much, much, much larger and more complex than that.

@srl295
Copy link
Member

srl295 commented Nov 23, 2019

I don't understand why localization is "tacked" on to node like this. Surely date formats for 100 or so countries can't be more than a kb or so of additional weight.

Not sure what you mean by "tacked". We discussed this way back in 2014 nodejs/node-v0.x-archive#6371 (comment) , this was a deliberate and theoretically well documented decision to avoid doubling the download size of node.

@cawoodm
Copy link

cawoodm commented Nov 28, 2019

What I mean is that the JavaScript experience is core + modules and now it's core + modules + thisOtherThing. It makes developing and operating node a pain since I now have to manage a dependency and environment variable instead of just installing a module. In fact, pains with this mean myself and others will drop ICU and install a 3rd party module. Whilst there may be 100+ countries there are not 100+ date formats - probably half a dozen or so.

@WickyNilliams
Copy link

For anyone that stumbles across this issue, it seems all locales are now included as of node v13: https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V13.md#2019-10-22-version-1300-current-bethgriggs

@srl295
Copy link
Member

srl295 commented Nov 27, 2020

@WickyNilliams yes, this is true.

@cawoodm
Copy link

cawoodm commented Nov 30, 2020

On Linux (CentOS) Node seems to ignore the system locale and produce US Date format MM/dd/yyyy:

(new Date()).toLocaleDateString()
'11/30/2020'

Anyone know where the locale can be set which Node uses?

[me@server~]$ sudo timedatectl
      Local time: Mon 2020-11-30 10:11:02 CET
  Universal time: Mon 2020-11-30 09:11:02 UTC
        RTC time: Mon 2020-11-30 09:11:02
       Time zone: Europe/Zurich (CET, +0100)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: no
      DST active: no
 Last DST change: DST ended at
                  Sun 2020-10-25 02:59:59 CEST
                  Sun 2020-10-25 02:00:00 CET
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2021-03-28 01:59:59 CET
                  Sun 2021-03-28 03:00:00 CEST
[me@server~]$ node
Welcome to Node.js v14.4.0.
Type ".help" for more information.
> (new Date()).toLocaleDateString()
'11/30/2020'
> .exit
[me@server~]$ date
Mon Nov 30 10:16:48 CET 2020

@dpd73
Copy link

dpd73 commented Jan 7, 2021

@cawoodm you could pass the locale you require as a parameter to .toLocaleDateString() no?

➜  ~ node             
Welcome to Node.js v15.5.1.
Type ".help" for more information.
> new Date(2020, 11, 1).toLocaleDateString('de-CH')
'1.12.2020'
> new Date(2020, 11, 1).toLocaleDateString('fr-CH')
'01.12.2020'

@srl295
Copy link
Member

srl295 commented Jan 7, 2021

Mon Nov 30

this looks like CentOS is choosing an English format also.

you can set LC_ALL such as:

$ env LC_ALL=de_CH.UTF8 node -p 'new Date().toLocaleString()'
2021-1-7 12:59:11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
i18n-api Issues and PRs related to the i18n implementation.
Projects
None yet
Development

No branches or pull requests

10 participants