Fix time range selector timezones

[neonnoon]

This PR removes all uses of date-fns-tz (except from test code). In my opinion, date-fns-tz actually complicates things significantly. From a time range point of view, there are no timezones, there's a start and end timestamp. So, the timezone only becomes relevant for display.

Intl.DateTimeFormat [1] handles this well. In my opinion, date-fns-tz can be useful to handle string to timestamp if a timezone is involved, i.e., figuring out the timestamp of "17 Mar 11:05".

If I understood things right, there's actually three timezones involved, local time, utc, and zoned time. Having the browser (or the tests) run in Europe/Zurich looks correct, using GMT though shows the discrepancy.

[1] https://caniuse.com/?search=DateTimeFormat

[neonnoon]

Before, correct when browser is in CET (start of next interval is end of previous):

Before, incorrect when browser time is in GMT (one hour missing in DST crossing):
(edit: and "now" time is quite off as well)

After, issue is fixed when browser time is in GMT (start of next interval is end of previous):

For completeness sake, correct behaviour also when browser is in CET:

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[neonnoon]

Updated node from 12 to 14. v12 did not yet contain full ICU support by default, see:
nodejs/node#19214

@justmejulian , @sosostris , you might wanna check this on your internal builds as well?

[nicholas-os]

Thank you Mezzo!

[neonnoon]

Thanks for the review, @nicholas-os . @justmejulian , do you also wanna have a quick look?

[neonnoon]

Discussed with @sosostris , @justmejulian & Thomas, merging now.

[Sakai-san]

you can do destructuring here :

const TimeRangeNavigationBar = (props) => {

const TimeRangeNavigationBar = ({from, lowerBound}) => {

[justmejulian]

Looks loads cleaner and fixes the failing tests. Thanks!

[sosostris]

@neonnoon I merged all the changes to local repo and somehow the tests were failing due to formatting (the values are all correct), like this:

Expected: "01.11.2020, 01:59 - 02.11.2020, 00:59"
Received: "11/01/2020, 01:59 AM - 11/02/2020, 12:59 AM"

But the tests are all passing here, so it's super weird. Checked a bit together with @Sakai-san and we found that the implementation of the method Intl.DateTimeFormat seems to vary with machine-os-language-set-up, e.g. there are similar issues reported here https://stackoverflow.com/questions/52797070/intl-datetimeformat-with-format-options-doesnt-work-for-it-ch

I will create a ticket to follow up with this. It would be nice to unify all the display to be one format :)

[neonnoon]

Ah.. I had the same issue.

See build result: See https://github.com/open-ch/pyrene/runs/2129628724
Fixed for Github like so: fa79374
Also mentioned further up in this thread: #6 (comment)

You might have to check the bamboo build agents.