Date serialization issue while displaying timestamp

[iscanegemen]

Bug Report

Using local timestamp in Perspective results in a time zone difference when the Perspective-Viewer updates based on UTC timestamp. We have created a repository for the issue where you can find the steps we have followed to reproduce the problem.

Steps to Reproduce:

1. Go to https://github.com/kryaksy/perspective-poc/tree/date-serialization-issue Github repository. Make sure that you are under the date-serialization-issue branch, not the main branch.
2. Under the README section, there is a link for the demo. Click on that.
3. Choose a date from the UTC Datetime selection area on the top left corner of the page.
4. The table will update shortly.
5. Observe the difference between the UTC timestamp and the value that the Perspective-Viewer displays.

Expected Result:

The exact string representation of the timestamp that the user has chosen.

Actual Result:

The date that's displayed on Perspective has a time zone difference caused during the serialization process.

Environment:

Our Perspective version is up-to-date.

[texodus]

Thanks for the detailed report and repro!

I believe Perspective is correct here, this is a quirk in datetime-local - see https://bugs.chromium.org/p/chromium/issues/detail?id=328524

Perspective treats numbers in datetime columns as UTC timestamps, but this is not what valueAsNumber returns. You can verify this directly in the console:

x = $0.value
> '2022-01-10T17:00'

new Date(x)
> Mon Jan 10 2022 17:00:00 GMT-0600 (Central Standard Time)

+new Date(x)
> 1641855600000

new Date(+new Date(x))
> Mon Jan 10 2022 17:00:00 GMT-0600 (Central Standard Time)

y = $0.valueAsNumber
> 1641834000000

new Date(y)
> Mon Jan 10 2022 11:00:00 GMT-0600 (Central Standard Time)

new Date(+new Date(y))
> Mon Jan 10 2022 11:00:00 GMT-0600 (Central Standard Time)

EDIT: To clarify, Perspective also displays all datetime column values in the browser's local time, which is the default for the JavaScript Date type. The specific issue with your example, however, seems to be that valueAsNumber is not the correct UTC representation of the local time displayed in the <input> itself.

[iscanegemen]

Thanks for the explanation @texodus.

If I understood correctly, datetime column values will display localized values independent from if it is "$0.valueAsNumber" or "$0.value". This situation causes some unwanted representations in our case. What I mean is that we want to input a "datetime" value as utc timestamp and display as utc datetime. Is there any way to skip localization and show as it is?

[jkusa]

@texodus any updates/thoughts on this? #1932 was a great addition and solves this issue for DataGrid. However, there still remains a need for this type of functionality in the other visualizations. Would setting a default display timezone make sense here?

[cythrawll]

So we have a usecase where we have global user base (that is to say in different timezones) But they all want to see reporting in a single timezone, UTC (As this is our reporting standard). Seeing the datetimes switch to use their local timezone is causing confusion. Datagrid timezone config is awesome but it's a bit jarring when switching other visualizations that doesn't keep the datagrid setting.