OH3: ZonedDateTime and DayJS Problem

[secureHAB (Horst M.)]

Dear community,
I try to show some dates in an oh3-widget by parsing a string with the dayjs-integration. But I can’t get it to work to show the right date-time.

My String Item stores following example string (length varies, structure always the same, splitting by ‘_’):
2021-05-12T20:00+02:00[Europe/Berlin]_2021-05-15T20:00+02:00[Europe/Berlin]

In the oh3-widget I created an oh-repeater component which iterates over an array, which I create by items[loop.dayString].state.split('_').
When I leave the `[Europe/Berlin]’ part in the String, the dayJS can’t create a proper date-time representation.

If I remove the `[Europe/Berlin]’ part in the String, the dayJS creates a proper date-time representation, but in the wrong TimeZone (GMT). My host system is running in TimeZone UTC+2 and the Docker-Container (witch serves openHAB) gets the TimeZone from the host system. I checked in the Docker-Container - TimeZone is CEST. So the timezones are the same…

Summarize

• Given String: 2021-05-12T20:00+02:00[Europe/Berlin]
• Inject into dayJS in oh3-widget: not possible to create date-time representation
• Remove content between [] ==> 2021-05-12T20:00+02:00
• Inject into dayJS in oh3-widget: wrong TimeZone representation (it gets GMT)
  • Host system and Docker-Container have CEST (UTC+2)

Problem

• How to properly parse ZonedDateTime.toString with dayJS to get proper DateTime representation in oh3-widget

[rossko57]

@secureHAB

Inject into dayJS in oh3-widget: wrong TimeZone representation (it gets GMT)

Doing what it is supposed to I think, parsing to UTC

@secureHAB

Host system and Docker-Container have CEST (UTC+2)

Who cares, you’re working in the browser here.

This looks helpful?

Timezone · Day.js

I’m intrigued by the “guess” option

[secureHAB (Horst M.)]

@rossko57

Doing what it is supposed to I think, parsing to UTC

But why is it parsing to UTC when proper TimeZone is given in the String?

@rossko57

Who cares, you’re working in the browser here.

I think it is important, because the browser gets the TimeZone from the host system it is running on. Therefor the javascripts in the browser also have a context of the host TimeZone given by the browse. Therefor the javascript libraries should get then the right TimeZone.

@rossko57

I’m intrigued by the “guess” option

okay, this functionality looks interesting
I will check it out and will respond later to that!
Thanks for pointing this out!

[rossko57]

@secureHAB

But why is it parsing to UTC when proper TimeZone is given in the String?

Because you didn’t tell it to do anything different? It’s exactly the same moment in time, internal representation doesn’t matter much.
https://day.js.org/docs/en/timezone/parsing-in-zone

@secureHAB

I think it is important, because the browser gets the TimeZone from the host system it is running on.

Still don’t care what the host system timezone is, you are working in the browser.
You just get a timestamp, with necessary timezone information.
Now, you have to decide whether you want to display that timestamp in the host supplied timezone, or in the viewer’s timezone. It’s your choice.