js-joda time.ZonedDateTime.now() is returning America/Mexico with DST although the country stopped using it

[adicorrales]

The block now in rules is returning the time in DST for Mexico (UTC-5) since the first Sunday of April, although the country stopped using it last year. The system time (Ubuntu, all up to date) is OK and java time.ZoneDateTime.now() returns the correct time (UTC-6)

Expected Behavior

now should return UTC-6 for Mexico since we are not using DST anymore.

Current Behavior

now is returning UTC-5

Possible Solution

According with Rich Koshak in the community forum, maybe check and upgrade the version of js-coda.

Steps to Reproduce (for Bugs)

1. Log a block with core now block
2. in the log, the timestamp is UTC-6, but the response states UTC-5

Context

The block is use as a condition in a rule that now is triggering 1 hour before it should.

Your Environment

• Version used: 4.1.2 release build
• Operating System and version: Ubuntu 22.04

[florian-h05]

I have updated JS-Joda to the latest version with version 4.9.0 of openhab-js.

Can you please upgrade openhab-js to the latest version (4.9.0)? Please be aware of a breaking change for Item.type, read the CHANGELOG.

If the issue persists, please file an issue at https://github.com/js-joda/js-joda/issues and link it here, so we have the reference.

[adicorrales]

Upgrading openhab-js did not solve the issue. reference to the report in js-joda git.

https://github.com/js-joda/js-joda/issues/719

[adicorrales]

Joda's git answer:

Hello @adicorrales, thanks for reporting this issue. The latest version of js-joda is using 2023c of iana tz db https://www.iana.org/time-zones, what's a bit behind the latest version there is 2023d and 2024a. I can update that in the next days. But the change about Mexico DST is included in 2022f (https://mm.icann.org/pipermail/tz-announce/2022-October/000075.html) therefore, when using the latest version of @js-joda/timezone version 2.18.3. Is your project using the latest version of js-joda ? If so could you give a more concrete example? The following test with latest js-joda version seems correct to me ZonedDateTime.now(ZoneId.of('America/Mexico_City')).toString(); // '2024-04-14T01:40:51.924-06:00[America/Mexico_City]'

[florian-h05]

Can you please check if you have disabled injection caching? Otherwise the add-on will not use the manually installed openhab-js, but the bundled one.

We are using timezones package version 2.18.3, so I guess it’s an issue with your installation not using the latest version.

[adicorrales]

I disabled cache here (and restart the service). I updated openhab-js according to the git instructions, but is there a way to check which version do I have (I'm using ubuntu)?

[florian-h05]

Please put console.log(utils.OPENHAB_JS_VERSION) into a JS script and run it.

[adicorrales]

Ok, something went wrong with the update... I have 4.7.3 and I'm getting a permission error (Although yesterday the "update" seems ok) Let me check again what's wrong.

[adicorrales]

Nope. Now on 4.9.0 and the now in joda still return DST:

2024-04-14 09:36:16.832 [INFO ] [nhab.automation.script.ui.dd2c8c5122] - 4.9.0
2024-04-14 09:36:33.174 [INFO ] [ab.automation.script.ui.quick_script] - 2024-04-14T10:36:33.169-05:00[SYSTEM]
2024-04-14 09:36:33.179 [INFO ] [ab.automation.script.ui.quick_script] - 2024-04-14T09:36:33.175942417-06:00[America/Mexico_City]

[florian-h05]

I guess the second timestamp is from Java DateTime, the first is JS-Joda. I would suspect an issue here with the SYSTEM timezone.

Can you please check the result of this?

time.ZonedDateTime.now(time.ZoneId.of("America/Mexico_City"));

[adicorrales]

Sure! Running this:

var deibich_blockly_ZonedDateTime = Java.type('java.time.ZonedDateTime');
console.info((time.ZonedDateTime.now()));
console.info( time.ZonedDateTime.now(time.ZoneId.of("America/Mexico_City")));
console.info(deibich_blockly_ZonedDateTime.now());

returns the right UTC (-6) Except for [System] with time.ZonedDateTime.now()

2024-04-17 09:37:28.689 [INFO ] [nhab.automation.script.ui.eb1ab7c731] - 2024-04-17T10:37:28.687-05:00[SYSTEM]
2024-04-17 09:37:28.691 [INFO ] [nhab.automation.script.ui.eb1ab7c731] - 2024-04-17T09:37:28.690-06:00[America/Mexico_City]
2024-04-17 09:37:28.693 [INFO ] [nhab.automation.script.ui.eb1ab7c731] - 2024-04-17T09:37:28.692501662-06:00[America/Mexico_City]

[florian-h05]

Hmm, the problem we have with openhab-js is, that we don’t know the timezone the user is in, therefore we default to SYSTEM. openHAB‘s Java part knows your timezone because you set it in the settings I guess.

Which OS has your openHAB host? Which timezone setting and which time does it show?

[adicorrales]

Ubuntu (Xubuntu) 22.04.4:

(At 10:19 local time)

xxxx@xxxx:~$ timedatectl
               Local time: mié 2024-04-17 10:19:55 CST
           Universal time: mié 2024-04-17 16:19:55 UTC
                 RTC time: mié 2024-04-17 16:19:55
                Time zone: America/Mexico_City (CST, -0600)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no