Future DST changes incorrect for Europe/London

[coatesap]

Apologies if this is effectively a duplicate of other outstanding timezone-related issues.

At the moment, if we ask what the UTC equivalent of 2023-03-26 17:00 in Europe/London is, Spacetime tells us that it's 17:00:

console.log(spacetime('2023-03-26 17:00', 'Europe/London').format('iso-utc'))
// outputs 2023-03-26T17:00:00.000Z

Whereas we know that in 2023 the DST change will have already taken place at 01:00 that morning, so the correct output would be 2023-03-26T16:00:00.000Z.

Is this because zonefile/iana.js is currently only storing a single year's worth of DST changes per timezone?

If so, this is a big problem for regions where the DST change occurs on a different day of month each year. Here in the UK it's the last Sunday of March. It means we can't deal accurately with dates/times from anything other than the current year. If there's a plan for how to solve this, I may be able to put some time towards it.

[spencermountain]

hey Andy, yep you're right. I have a plan to support the 'last sunday' patterns, but have had a busy summer and haven't got to it yet. you can see the start of the work here, if you'd like to join me.

I've looked in earnest for a collection of these folk patterns, like 'last sunday', and it's incredible that they are found nearly nowhere. I honestly think this library will be the first to code them. cheers

[spencermountain]

hey andy, i've started work on this and hope to ship it next week. it's a big change cheers

[ricardotorquato]

Hello guys, is there any news on this? Because we just entered DST in Europe and it seems like the lib is not considering it causing some issues over here.

[spencermountain]

hey Ricardo, can you reproduce this? seems to be working for me cheers

[ricardotorquato]

Sorry I was on the wrong version. Latest work just fine! thanks!

[TCScouts]

Hey, could anyone inform me in which version these changes were released, please?

[HowieSquires]

Hey, when is this planned to be released, please?

[finiteinfinity]

Hey @spencermountain, apologies if you've been asked this 1000 times already, but given that you're planning a new release soon, will this include the correct DST dates for 2024 in Europe/London?

Also, if you're looking for help on the DST pattern improvements, I'm happy to contribute my spare time. I used to work with Andy, so I'm well aware of the headaches this is likely causing many people.

[spencermountain]

hey Harry, thanks. Yep 2024 dst dates will ship very shortly. It's not a huge amount of work, i just try to do it after all the latest dst changes for the year have taken effect. December is the lightest spot. Not a perfect system.

Yeah, this spring I got close to a 'infinite spacetime' release, where it uses the folk dst patterns instead of tzdb. It's cool. Besides the bugs, it ended up being both larger and slower than the current library. It involves moving away from the js Date object completely.

In a perfect world, this part gets written in rust, packed into a tiny wasm binary, and spacetime is a nice little api wrapper. This is where i'm at, thinking about this problem going forward.

In the meantime, we could ship a spacetime/2024, spacetime/2025 or something, which would probably be pretty cumbersome. It's also never clear what DST changes will happen, more than a couple months in advance.

I think it's a situation where there's tiny, fast, and perfect, but you can only chose 2. At the moment we're tiny and fast but off by an hour, within a couple hours of a DST change. ¯_(ツ)_/¯ cheers

[spencermountain]

hey @finiteinfinity - dst changes updated to 2024 in 7.5.0 cheers

[finiteinfinity]

Thanks @spencermountain! Missed your comment, but yes I agree that would be the ideal solution. Honestly I've never written a line of rust in my life (much prefer Go), but if you would like help either way, then just reach out