Node JS current DST rules for Chile

Question

According to specifications, Node JS (ES5) should use current dts rules when working with Date objects. Current means "for now", not for a particular date. That's not perfect, but enough for me at this moment.

Currently that rules are wrong (due to law changes in Chile).

Simple probe:

console.log(new Date()) 
Mon Apr 08 2019 12:48:08 GMT-0300 (Chile Summer Time) {}

shows "(Chile Summer Time)" at the end of the default toString for a date. Actually we are not in Summer Time (it ended two days ago) and current offset should be -4 and not -3.

I tried upgrading Node to lates stable release and didn't work. I Don't want to change a lot of code (in production) to use moment.js or equivalent.

Is there any way to update DST rules in an existing Node JS installation?

Thanks in advance

-- Edit --

TZ environment variable is empty.

Tested on Mac OSX (Mojave 10.14.4) and Red Hat (4.8.5-36)

moment.js recognizes zone correctly ("America/Santiago" whith moment.tz.guess())

Answer 1

The change for Chile you mentioned was part of IANA TZ data version 2018f, released in October 2018.

Node exposes the tz version via process.versions.tz. The current shipping 10.15.3 LTS version returns 2018e, which explains why you aren't seeing the update. I assume this will be updated at some future date.

Node gets its IANA data via ICU. There are instructions for different ways to compile Node's ICU support (system-icu, small-icu, full-icu) documented here, which apply if you are building Node yourself from source code. Alas, I cannot find any mechanism for updating Node's ICU data directly, without building Node yourself.

ICU has documentation on how to update time zone data without updating all of ICU. however, I cannot see anywhere that Node is taking advantage of this capability.

Thus, when it comes to updating Node's time zone data - Either it cannot currently be done, or it is poorly documented. Sorry, I don't have a better answer for you than that.

You did say you were using moment-timezone already, which ships its time zone data independently. If you use only moment functions (rather than the Date object), then you should get the correct result.