Use home's location timezone instead of client's one in UI

[NikolayKash]

The problem

See topic here https://community.openhab.org/t/oh3-main-ui-taking-into-account-server-time-zone-not-browser-time-zone/140177

Expected behavior

Shows all graphs in home's location time zone and do not take into account the computer timezone

Steps to reproduce

1. Change computer timezone to some one else from the server one

Your environment

runtimeInfo:
  version: 3.4.0.M2
  buildString: Milestone Build
locale: en-RU
systemInfo:
  javaVersion: 11.0.13
  javaVendor: Azul Systems, Inc.
  javaVendorVersion: Zulu11.52+13-CA

clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: false
    macos: false
    windows: true
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    os: windows
    pixelRatio: 1.25
    prefersColorScheme: dark
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 4
    language: en-US
    languages:
      - en-US
      - en
      - ru
    onLine: true
    platform: Win32
  screen:
    width: 1536
    height: 864
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: dark
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
  userAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
    like Gecko) Chrome/105.0.0.0 Safari/537.36
timestamp: 2022-10-10T19:32:53.111Z

Browser console

Browser network traffic

Additional information

[ghys]

This is indeed a problem.

The persistence endpoint returns epoch-based timestamps which are not fixed to a timezone.
Cf. https://github.com/openhab/openhab-core/blob/2bceba69549c6017485e5089c64d6131889aa76a/bundles/org.openhab.core.io.rest.core/src/main/java/org/openhab/core/io/rest/core/internal/persistence/PersistenceResource.java#L340
Example:

... {"time":1667834340000,"state":"590"},{"time":1667834400000,"state":"600"} ...

So they are sent as local time by the server and interpreted as local time by the client (the UI).

It's a bit convoluted to figure out if the timezones are different and perform the conversion (the server's timezone isn't always accessible).

ECharts has an open issue about this: apache/echarts#14453

Alternatively, one of these could be sent along with the request to the persistence endpoint to make the server aware of the client's timezone:

so it could take it into account and return timestamps converted to the client's timezone. There is no HTTP request header automatically sent by browsers which includes the local timezone so it would have to be in the request body's payload.

Of course, ideally proper timezone-aware date strings could be returned in these time fields instead of the UNIX timestamps (ECharts would interpret them properly I think) but this is API-breaking and potentially performance-hitting.

Also note that charts without a fixed period - so-called "dynamic" periods - always end by default to the current date & time, in the local timezone, in this case it might not match the end of the historical data.

@openhab/core-maintainers wdyt?

[NikolayKash]

@ghys

the server's timezone isn't always accessible

I think we have to relay on time zone set here settings/services/org.openhab.i18n and use this time zone to show datetime, as well to show 12/24 hours
this api http://xxxxx:8080/rest/services/org.openhab.i18n/config

This is not only related to analyzer view, also schedule (/settings/schedule/) view affected by this issue

[ghys]

this api http://xxxxx:8080/rest/services/org.openhab.i18n/config

This is what I meant by "not always accessible"; /rest/services is an admin endpoint. That's why it makes sense to let the server do the conversions (either to the requesting client's local timezone or to UTC).

[J-N-K]

The persistence endpoint returns epoch-based timestamps which are not fixed to a timezone. Cf. https://github.com/openhab/openhab-core/blob/2bceba69549c6017485e5089c64d6131889aa76a/bundles/org.openhab.core.io.rest.core/src/main/java/org/openhab/core/io/rest/core/internal/persistence/PersistenceResource.java#L340 Example:

... {"time":1667834340000,"state":"590"},{"time":1667834400000,"state":"600"} ...

So they are sent as local time by the server and interpreted as local time by the client (the UI).

I don't think this is correct. If I understand the code the timestamps are always epoch timestamps which denote a certain point in time (relative to 1970-01-01 00:00:00 UTC). So the client can always convert them to the timezone that is needed, without knowing the server timestamp.

Also the /persistence endpoints of the REST API allow transmitting a timezone together with begin/end values (e.g. 2023-05-20T20:00:00.000+02:00).

Also note that charts without a fixed period - so-called "dynamic" periods - always end by default to the current date & time, in the local timezone, in this case it might not match the end of the historical data.

For charts we should probably transmit a timezone that shall be used.