System time and OpenHab time out of sync

boardboy · September 10, 2024, 5:18pm

Hi,

I just did a full fresh install of OpenHabian running openhab 4.2.1

My system shows the correct localtime through

timedatectl

output:

               Local time: Tue 2024-09-10 19:12:16 CEST
           Universal time: Tue 2024-09-10 17:12:16 UTC
                 RTC time: n/a
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

How ever the logfiles show a time running 1 hour behind.

2024-09-10 18:15:10.217 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'Verlichting_TV_Vermogen' received command ON

I created a rule to update the time on an item just to be sure:

test.postUpdate(new DateTimeType())

The item is also 1 hour behind.

Interestingly the regional settings in OpenHab settings tell me the time zone is:

(GMT+1:00) Europe/Amsterdam

Which is 1 hour difference from the timedatectl output.
I’ve searched the forum, but I have no luck so far.

Bart

boardboy · September 10, 2024, 5:36pm

This seems to be related to a timezone database issue in Java 17

github.com/corretto/corretto-17

Europe/Amsterdam timezone is now broken due to error in tz update 2022c.

opened 10:40PM - 19 Oct 22 UTC

rzwitserloot

This is the last version with the correct tz info for Europe/Amsterdam: https…://github.com/corretto/corretto-17/blob/9068185db6a9a4227a16908297e5ee68f605e5fd/make/data/tzdata/europe#L2215 The next commit basically says 'amsterdam is exactly like brussels'. Amongst other things, it changes the moment when Europe/Amsterdam joins the modern age, timewise, from the correct May 16th 1940, to the incorrect May 20th 1940. (It's correct for Brussels; it's not correct for Amsterdam. Nazi germany changing timezones on countries they occupied, and said countries not reverting to their pre-war state after being liberated, explains these dates). I'm not familiar enough with the rules about timezone stuff to know if this is an error in corretto or an error in tzdata. However, the upshot is rather drastic. Code like this: ```java Date d = new Date(40, 2, 1); // cruddy old broken API, I know System.out.println(d.getTime()); // wrong answer! ``` is broken for any date before may 20th (not just between may 16th and may 20th 1940). At least, it's clearly wrong in that range, and before that range, it's inconsistent with prior versions. I can run this code: ```java Date d = new Date(37, 8, 2); System.out.println(d.getTime()); ``` And when I upgrade/downgrade between Corretto v17.0.4.9-1 and Corretto v17.0.5.8-1, this prints different numbers, without changing the TZ at all (it's set to Europe/Amsterdam on this machine, with the RTC on UTC, on ubuntu running on ec2). I believe v17.0.4.9-1 gives the right answer, and v17.0.5.8-1 gives the wrong answer. This has far reaching deleterious effects: for example, DATE columns in h2 now report the wrong date (off by a day) for any date prior to may 20th, 1940. Evidently because h2 stores millis and not y/m/d for some reason. Any code anywhere that flips between DMY and milli-based storage mechanisms will flat out break for anything prior to may 20th 1940, even when consistently applying the Europe/Amsterdam timezone. Please advise if the tzdata in corretto is just copied from elsewhere, and that therefore I should be filing this bug elsewhere. In the mean time, for all affected: Downgrading is the only way I can fix this, if you want e.g. h2 databases to not be unfixably broken if they are storing dates prior to May 20th 1940 and your server is setup in Europe/Amsterdam zone.

I’ve installed the version from that comment and now it works as expected!

mstormi · September 10, 2024, 7:31pm

I’ve patched openHABian, could you attempt to reinstall to see if that fixes it ?

boardboy · September 10, 2024, 7:42pm

I appreciate your swift response, but I’m happy that I’ve got my automation back up after a week of issues due to a failing Pi.

I won’t have a lot of time to test it, and I have to be friendly to a slight annoyed better half already since the initial troubles of the home setup failing

I might have time in a couple of weeks.