NTP Time Zone problem and time sinchronization

Add-ons Bindings
, ,
1

Hi,

I just upgraded OH to Beta3 and it has some strange behavior.

-OH2 running on a Raspberry Pi
OS configured with correct local time (For example 16:00) (UTC+2)

-My NTP thing is correctly configured (I also tried with different configurations such Europe/Berlin)
hostname: 0.pool.ntp.org
Timezone: Europe/Madrid
Locale: es_ES

-The time I get on my Sitemaps is -2h (14:00) which corresponds to UTC time

Why the time is not getting the correct timezone?

2

I tested as well, also think something is wrong.

Added an issue for it in the tracker

3

@igor

The background of this issue due to the formatter class always using the default time zone for the instance of the Java virtual machine. See also http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html
This class is used to display the time in the UI. So though the binding is sending a object containing the right timezone to the OH framework, the output to the UI ignores it

I made an update to the binding where you can output a string channel which does allow you to actually output the time in the timezone you defined.

4

@marcel_verpaalen

Thanks for your contribution.

I see the files you changed on: https://github.com/eclipse/smarthome/pull/1693

Now my question is how to get this update into my OH b3.

5

I just fount out that is not only the NTP biding time the one that is wrong.

-The time that shows the last updated time of the weather binding, also shows the UTC time, instead of the zone time.

-The time of the astro biding also shows the times in UTC.

Will your changes in NTP binding fix the timing errors also in other bindings or this is a problem that has to be addressed somewhere else?

6

The background of this issue due to the formatter class always using the default time zone for this instance of the Java virtual machine. See also
http://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html

The second issue is the default format

The capital Z at the end means the time is displayed with a +1000 sort of notation. The z Will show the more readable timezones. E.g CET

Still need to find out what would be the impact of changing this. (As this may impact interfaces that rely on that notation)

7

If you have an b3 online version, I think you can uninstall ntp binding and add it again in the extensions page.

Than add a new ntp item, as the new string channel will not appear on existing things (a known issue/feature unrelated to ntp binding)

8

No, the problem seems to be much deeper in Smarthome/OH. From what I see the following is happening:

For all Types, there is the general assumption that they should be reconstructable from their string representation, i.e. typeX.equals(new TypeX(typeX.toString())) should be true.

This is currently not the case for the DateTimeType, since the toString methods converts from a calendar to a Date Object, removing the timezone information which is contained within the internal Calendar object. (some other info is lost as well, e.g. firstdayoftheWeek etc)