Weird bug locale dates 1900 and before

Am I missing something? Dates are wrong for 1900 and before:

https://codesandbox.io/s/ww5859zjwk

Very important: this is happening when I set my windows timezone to UTC +01 Madrid. If I set it to UTC +00 London the same bug occurs for 1922 and before. This is only happening in Chrome.

[icambron]

This is the weirdest bug yet! I figured it out and unfortunately I don’t have a solution. Here’s the problem: In Madrid, in 1900, the offset from UTC was 14 minutes and 44 seconds. It’s crazy but true. You can go here and pull down the dropdown to 1900 and see it.

Unfortunately, the JS Date methods will only give TZ offsets in minutes:

new Date(1900, 0, 1).getTimezoneOffset() //=> 14

which is of course wrong by 44 seconds. Luxon has some complicated logic built for handling a host of browser DST bugs and for implementing non-local time zones. That logic depends on getTimeZoneOffset. The result is that Luxon is off by 44 seconds on the time, resulting in:

DateTime.local(1900, 1, 1).toJSDate().toString()
'Sun Dec 31 1899 23:59:16 GMT-0014 (Central European Standard Time)'

The bug only happens in Chrome because it’s the only browser with good enough historical data to have this problem. I’m not sure what to do here:

• There may be a way to get a more precise offset by parsing some string, but given that Luxon does this computation on most operations, that’s probably too painful performance-wise, not to mention brittle. (Edit: I haven’t found such a way anyway)
• Ideally, browsers should provide something like getTimezoneOffsetMilliseconds() but they don’t
• There might be a way to avoid doing this complicated logic on local dates, but that has many other downsides, and anyway, the same problem would show up with your computer set to somewhere else but your code using “Europe/Madrid” explicitly.

So barring a time machine to go back and change Spain’s historic offsets, I’m not sure how to fix this.

I wasn’t able to reproduce any issues with London.

[icambron]

I’m going to close this. While I agree this is a bug, it’s not one that Luxon can fix, so it’s just taking up space in the issue list.