NTP binding - can't create an item representing the abbreviation for the time zone

Add-ons Bindings
,
1

Hi,
I use the NTP binding in my Openhab2 system and it works in a perfect way if I set the two items linked to the two channels as described in the documentation. In this way I can insert both a DateTime and a String item showing the current date and time in my sitemap.

In the last days I have been trying to create an item containing the abbreviation of the time zone of the binding dateTime channel, but I can’t obtain exactly what I would like. According to
https://docs.oracle.com/javase/7/docs/api/java/util/Formatter.html#syntax
in the items file I set
DateTime TimeZone "time zone: [%1$tZ]" {channel="ntp:ntp:house:dateTime"}
and in the sitemap file I set
Text item=TimeZone
and the result is that the sitemap shows
+01:00
but I would expect, and I would like to obtain, a
CET

I tried to change the item type from DateTime to String but the value showed in hte sitemap is the same.

Then I tried to follow this link
https://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html
even if I’m not sure I could interpret everything in the right way and so
in the items file I set ( (I changed the parameter Z to z)
DateTime TimeZone "time zone: [%1$tz]" {channel="ntp:ntp:house:dateTime"}
and in the sitemap file I set
Text item=TimeZone
and the result is that the sitemap shows
+0100
but as before I would expect, and I would like to obtain, a
CET

I tried again to change the item type from DateTime to String but the value showed in hte sitemap is the same.

So, would anybody know how to help me to understand what I’m doing wrong? According to “Date/Time Conversions” section of the first documentation I linked, I would expect that using [%1$tZ] for the state presentation I could obtain a string representing the abbreviation for the time zone.

Bye.

2

The sitemap uses the Formatter provided by Java so the Z should work. To my knowledge, OH has done nothing to change this behavior.

I ran a quick test and can confirm the same behavior.

3

@rlkoshak Thank you for answer Rich.

So I understand that you write that, to your knowledge, in order to obtain a string representing the abbreviation for the time zone should be used [%1$tZ] for the state presentation. And that is what I tried, but without success.

I just can’t clearly understand if the result of your test was successful because you obtained an item value with the abbreviation for the time zone (and that would imply that something is wrong in my configuration or in my system) or if you couldn’t obtain that string (and so it would mean that for both of us the behavior of the system is not the expected one).

Bye.

4

It wasn’t.

I ran a quick test and can confirm the same behavior.

Meaning I’m not getting the abbreviated time zone either. I’m seeing the same thing as you.

5

Just confirmed the basic java types (Calendar, Date, ZonedDateTime) work correctly.

Calendar c = Calendar.getInstance();
Date d = c.getTime();
ZonedDateTime z = ZonedDateTime.now();
String dOut = String.format("%1$tZ", d);
System.out.println("Val 1: " + dOut);
String calOut = String.format("%1$tZ", c);
System.out.println("Val 2: " + calOut);
String zOut = String.format("%1$tZ", z);
System.out.println("Val 3: " + zOut);

Output:

Val 1: EST
Val 2: EST
Val 3: EST

Guessing one of OH’s derived types is munging this.

6

@rlkoshak Thank you Rich for making the specification.
Now it’s completely clear for me that there is a problem but that is not in my configuration files.
I know this time zone abbreviation issue is not a big problem but I think it could be good to try to solve it.

7

@emme-oh, you found this defect, would you like to create an issue for tracking it in the Smarthome tracker?

8

@namraccr I’ve just opened an issue in the eclipse/smarthome repository inside github about the problem we started to discuss here


I didn’t know what the Smarthome tracker is but I guessed that your suggestion was to open an issue there.

9

I would expect the string version of the channel to work
The reason for using that string version is due to the fact that different UI’s have don’t apply the same formatter for the dateTime type. (this was the whole reason for adding the string channel)

This is not an issue of the NTP binding, but applicable for all bindings that display dateTime type

10

I’ve managed to obtain an item representing the abbreviation for the time zone using another way instead applying the [%1$tZ] formatter to the item linked to the dateTime channel.

I set the items file in this way

String ActualTimeString “actual time (string): [%s]” {channel=“ntp:ntp:house:string”}
DateTime TimeZone “actual time zone: [%1$tZ]” {channel=“ntp:ntp:house:dateTime”}
String TimeZone_String “actual time zone (string): [%s]”

and I added this to my rules file

rule “actual time zone program”
when
Item TimeZone changed
then
val timezone_String = ActualTimeString.state.toString.split(’ ').get(2)
TimeZone_String.postUpdate(timezone_String)
end

The result is that the TimeZone_String item gets updated with the three character abbreviation related to the current time zone.

I mark this discussion solved because the aim was to have an item filled with the abbreviation for the time zone and that has been obtained, even if in a different way than with the [%1$tZ] formatter. The problem about the formatter could be further discussed and investigated in the issue opened in github.

Bye

1 Like