Issue 68549: Timezones and offsets are not properly used when working with dates

[ComaVN]

This is a fix for bug #68549

It's not as clean as I hoped, but it's extensively unit tested

The fix would probably be simpler if the timelib_time_offset type also contained the timestamp of the next DST transition, but that seemed like too big of a change to me.

[cmb69]

Please submit PRs for ext/date/lib/* to https://github.com/derickr/timelib.

[ComaVN]

Please submit PRs for ext/date/lib/* to https://github.com/derickr/timelib.

I'd do that, but I'm having trouble figuring out how... the last commit on PHP-7.4 seems to indicate it's version 2021.5, but that version's code doesn't look to be the same as what's in ext/date/lib...

[cmb69]

timelib is on 2021.10 right now. Still, try to fix it there, and then a back-port of the fix might be viable.

[ComaVN]

timelib is on 2021.10 right now. Still, try to fix it there, and then a back-port of the fix might be viable.

According to CONTRIBUTING.md, bugfixes are against the lowest branch first, right? and that's definitely not on 2021.10...

I'll see what I can do in https://github.com/derickr/timelib

[ComaVN]

I managed to fix it a lot easier, without changing timelib. I still think there's a bug there, it's just not noticable here anymore.

[derickr]

This doesn't look right. The function should be able to be called regardless of whether the sse is up to date

[ComaVN]

The function should be able to be called regardless of whether the sse is up to date

Well, it clearly cannot. I'm currently busy trying to get an MR working for timelib tho.

[cmb69]

I'm currently busy trying to get an MR working for timelib tho.

That is derickr/timelib#121.

[derickr]

This PR can be closed, as the relevant code has made it into timelib now and will automatically filter down here when it gets merged.