Luxon: toFormat() does not work with i18n and fails on Node.js

[PierreKauffmann]

Trying in Node.js with the following (this is the documentation example):
DateTime.fromISO('2014-08-06T13:07:04.054').setLocale('fr').toFormat('yyyy LLL dd');
I get the result: "null Aug null".

The Node app runs on a server in UK (which has not brexited yet ;-) and rather than the French "aou." for month I get the English "Aug". Moreover day (dd) and year (yyyy) miserably fail ;-(

Luckily, the toLocalString works. But I need to handle various user format.

See screen shot.

[icambron]

You're going to have to give more info. For Node with Intl support, I get this:

> DateTime.fromISO('2014-08-06T13:07:04.054').setLocale('fr').toFormat('yyyy LLL dd');
'2014 août 06'

For Node without it, I get:

> DateTime.fromISO('2014-08-06T13:07:04.054').setLocale('fr').toFormat('yyyy LLL dd');
'2014 Aug 06'

What version of Node are you running?

[PierreKauffmann]

Hi,

I'm using "v10.12.0" I haven't yet tested with 10.13

Cordialement, Pierre Kauffmann

---

Pierre Kauffmann : [email protected]

Le mer. 17 oct. 2018 à 22:39, Isaac Cambron [e-mail] a
écrit :

You're going to have to give more info. For Node with Intl support, I get
this:

DateTime.fromISO('2014-08-06T13:07:04.054').setLocale('fr').toFormat('yyyy LLL dd');'2014 août 06'

For Node without it, I get:

DateTime.fromISO('2014-08-06T13:07:04.054').setLocale('fr').toFormat('yyyy LLL dd');'2014 Aug 06'

What version of Node are you running?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/moment/luxon/issues/348#issuecomment-430780528, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHnUtMRqXeICxd-4AmZTMaETSGOOMieHks5ul5WVgaJpZM4XZhvN
.

[trentjones21]

I was experiencing the same error when running my code using Firebase cloud functions. Upgrading my firebase functions from Node 6 to Node 8 fixed it for me.

[yvele]

I have the same problem on node 6 (I'm stuck with it) and yyyy format returns me null

[PierreKauffmann]

I even tried starting node with --with-intl=full-icu parameter: no sucess ;-(

[dvlsg]

Did you start node with --with-intl=full-icu, or did you _build_ node with that flag? IIRC that's a compiler flag, not a runtime flag.

There are a couple ways of providing the ICU data at runtime, though. A polyfill might work for you too? I haven't tried that with Luxon yet.

[icambron]

Let's separate a few things out here:

1. The OP is running Node 10 and it isn't working as expected. That's an issue; I just can't reproduce it so I haven't made any progress
2. @dvlsg is right that runtime flags aren't how you enable ICU (instead, follow the Luxon instructions here). However, that's neither here nor there, because Luxon doesn't fail like that in the absence of Intl; it just falls back to English
3. Node 6 doesn't support formatToParts and thus can't do Intl parsing and formatting whether or not it has access to the ICU data. That's just how it is. You can see that documented here.
4. edited That said, even Node 6 should be falling back to English, not spitting out nulls

@PierreKauffmann the only thing I can think of is to make super extra sure you're really running the version of Node you think you are. Can you check process.version in the same process you're testing Luxon? probably not the problem

[dvlsg]

FWIW, I wasn't able to reproduce in a variety of node 6 versions (6.0.0, 6.2.0, 6.6.0, 6.8.0, 6.10.0, 6.12.2), as well as 8.9.4, 8.12.0 or 10.12.0 on an en-US windows 10 box either. The following output english formatted strings for all of them, without any nulls (without any full-icu usage):

const DateTime = require('luxon').DateTime
const date = DateTime.fromISO('2014-08-06T13:07:04.054')
  .setLocale('fr')
  .toFormat('yyyy LLL dd')
console.log(date) //=> 2014 Aug 06

8.x versions _did_ both output a slightly different output (2014 M08 06), but I assume that's just the english format that Node 8.x happened to use for whatever reason.

[icambron]

@dvlsg Thanks for the testing. Yes, there shouldn't be a bug cause by missing formatToParts in Node 6, and it's supposed to just fall back to English in toFormat, like this. So I guess I don't see why people would be getting "null" as output even in that version and it's probably not a weird version issue after all.

On M08: Yeah, some builds of Node 8 don't have a default locale, so the fr falls back to undefined instead of en-us and the months have silly names. Luxon explicitly defaults you to English to avoid that because even without ICU but it can't prevent Intl's fallbacks for unknown languages, so you end up with "M08".

> new Intl.DateTimeFormat("en").resolvedOptions().locale
'en'
> new Intl.DateTimeFormat("fr").resolvedOptions().locale
'und'

[clicktravel-antonrand]

I've been able to replicate this through RunKit using node v6.15.0 and v7.10.1

See this example: https://runkit.com/embed/jzrkpma3oowz

It's fine for node v8+ upwards

[SamMatthewsIsACommonName]

can confirm updating firebase function form node 6 to node 8 fixed problem for em also

[leider]

I have a similar issue on node with full-icu and Intl polyfill:

/*eslint no-process-exit: 0 */
/* eslint no-console: 0 */
'use strict';


const IntlPolyfill = require('intl');
Intl.NumberFormat = IntlPolyfill.NumberFormat;
Intl.DateTimeFormat = IntlPolyfill.DateTimeFormat;

const luxon = require('luxon');
luxon.Settings.defaultLocale = 'de';
const now = luxon.DateTime.local();

console.log(now.toLocaleString(luxon.DateTime.DATETIME_FULL));
console.log(now.toFormat('yyyy/MM'));

process.exit();

leads to stack:

/JavascriptDev/JC-Backoffice/node_modules/luxon/build/node/luxon.js:2302
    return this.locale === "en" || this.locale.toLowerCase() === "en-us" || hasIntl() && Intl.DateTimeFormat(this.intl).resolvedOptions().locale.startsWith("en-us");
                                                                                                                        ^

TypeError: Intl.DateTimeFormat(...).resolvedOptions is not a function
    at Locale.isEnglish (/JavascriptDev/JC-Backoffice/node_modules/luxon/build/node/luxon.js:2302:121)

node v10.1.0 on macOS

may as well be an issue for Intl

[leider]

If I replace the lines

Intl.NumberFormat = IntlPolyfill.NumberFormat;
Intl.DateTimeFormat = IntlPolyfill.DateTimeFormat;

by

global.Intl = IntlPolyfill;

Everything works fine.

[matthiasg]

In order to have Node.js process international formats:

1. Add full-icu as a dependency
2. set NODE_ICU_DATA in the environment to the path of the module (relative from start or absolute, e.g node_modules/full-icu)

[leider]

Both settings are applied.

[matthiasg]

Both settings are applied.

Just to be clear, I am not using any polyfill just pure node with full-icu and NODE_ICU_DATA in the startup env with node 10.x (though not with the newest luxon)

[leider]

Do you have accustom compiled node? The pure download needs the polyfill to work.

[matthiasg]

@leider it is the default node (10.15.0) as downloaded from nodejs.org

See https://github.com/matthiasg/luxon-test

[leider]

@matthiasg thanks a lot for claryfying. The polyfill is indeed not needed. - My personal issue is closed thereby.

One more thing: I guess my observation still hits people in environments where the polyfill IS NEEDED. What's you opinion?

Greetings from Karlsruhe

[icambron]

OK, finally getting a chance to wade in here. A few different notes:

1. While I wasn't able to actually reproduce the Node 6 issue, I did eventually figure out what must be causing it. Fixed in ed85f23 and released in 1.19.2
2. The OP is still about Node 10, which I use every day and have never reproduced the issue. However, I suspect the fix to the Node 6 issues is the same.
3. @leider I think the issue with the polyfill is addressed by 3cb93b0, though I haven't tested it specifically with the polyfill. That fix is in 1.19.1

[matthiasg]

@leider did not see your comment earlier, I would he the issue is indeed addressed with 1.19.2 as described above. If you can test and still have that issue I would love to know.

[leider]

Will comment asap.

Am 23.09.2019 um 09:40 schrieb matthiasg [e-mail]:


@leider did not see your comment earlier, I would he the issue is indeed addressed with 1.19.2 as described above. If you can test and still have that issue I would love to know.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[leider]

works for me (although I don't need it anymore; changed my implementation to not require polyfill)