GMT+0119 timezone handling

[entioentio]

Between dates 30 June and 1 July of 1937 there's timezone change from GMT+0019 to GMT+0120. When using fromJSDate, the o property of DateTime object is a float, but only in FF & IE, not in chrome (didn't test other browsers).
I'm sure it's browser dependant and can be worked around in my front-end code, but the question is if shouldn't it be taken into consideration in the lib's code.

See the screenshot from FF:
js date,
.fromJSDate
.toFormat

edit:
PS. I know, that

3. Luxon shouldn't contain simple conveniences that bloat the library to save callers a couple lines of code. Write those lines in your own code.

...thus using the word "question". If it shouldn't be included, then just close the issue, please 🙏

[icambron]

I'm actually a little confused by the results there. It looks to me like it shifted from +1:19:32 to +1:20. My guess is that is that Chrome simply doesn't know about the 32 seconds, which unfortunately means Luxon doesn't understand it either. What exact time zone is this? (e.g. "Europe/Warsaw" or similar) I wasn't able to immediately find this historical data.

[GillesDebunne]

The offset was 19m 32.13s until July 1st 1937 (see UMT+00:20) in the Netherlands for timezone 'Europe/Amsterdam'.

This value is rounded to 19m in Chrome, and to 19m 32s in FF which results in the 79.5333333 of your screenshot.

#755 rounds the displayed offset to the minute, which will now display +01:19 in all browsers. However, since the offset is different between browsers, this may lead to discrepancies...

An option could be to always round the offset (expressed in minutes) in DateTime constructors.