PST to PDT is off by one day about spacetime HOT 10 CLOSED

hey Ricardo! yeah, nice find. I think we're still using 2017's dst dates.
rats, i gotta do that.
i'll try to get this today, or this at least week.
thanks for finding this.
cheers

from spacetime.

@spencermountain

My pleasure. Let me know if you need help testing.

from spacetime.

hey @ricardobanegas , wanna check out v3.2.0?
this is our first year-update, so may find some funny-biz.
https://runkit.com/spencermountain/5a84aad980921200129df457
cheers

from spacetime.

@spencermountain Initial tests look good! Will place code on test server and let our tester run through some deeper tests. I'll let you know.

from spacetime.

@spencermountain Sorry, I spoke to soon. There is still a bug in the conversions.

On 2018-03-11 I expect 12:00:00 to 14:00:00 to be the converted values, but I'm getting 11:00:00 to 13:00:00.

As mentioned, the timezone conversion happens 2018-03-11 02:00:00.

It seems the library understand the offset is -7 in the s.timezone().current object but not when doing the calculation.

This is produced by the same code snippet as above.

BEFORE 2018-03-11T19:00:00+00:00 AFTER 2018-03-11 11:00:00 {offset: -7, isDST: true}
BEFORE 2018-03-11T20:00:00+00:00 AFTER 2018-03-11 12:00:00 {offset: -7, isDST: true}
BEFORE 2018-03-11T21:00:00+00:00 AFTER 2018-03-11 13:00:00 {offset: -7, isDST: true}

Thanks again.

from spacetime.

Another bug on the same day. In the beginning of the day its returning -9 in offset. It seems the entire day 2018-03-11 is off by one hour.

BEFORE 2018-03-11T09:00:00+00:00 AFTER 2018-03-11 00:00:00 {offset: -8, isDST: false}
BEFORE 2018-03-11T10:00:00+00:00 AFTER 2018-03-11 01:00:00 {offset: -8, isDST: false}
BEFORE 2018-03-11T11:00:00+00:00 AFTER 2018-03-11 03:00:00 {offset: -7, isDST: true}
BEFORE 2018-03-11T12:00:00+00:00 AFTER 2018-03-11 04:00:00 {offset: -7, isDST: true}

from spacetime.

A tip that might be helpful: pendulum for Python makes perfect calculations regarding timezones and DST. Maybe you could extract that algorithm and put it in spacetime. Although it makes use of very precise zoneinfo database.

from spacetime.

hey @ricardobanegas - just confirming, this is for America/Los_Angeles on the day of the dst change right?
Yeah, i think the dst-change we have is an hour late. Would that make sense? I think it's a "3am becomes 2am" confusion on my part.

@dekoza ohh pendulum is really cool! thank you for sharing that.

yeah, we're definitely at the point in this project where we can start diffing results with other libraries to find the sore-spots in ours. Been shy about doing that so far.

from spacetime.

@spencermountain corrects its America/Los_Angeles we are talking about.

from spacetime.

hey, good find. looks like all the dst-changes were off by one hour.
fixed in v4.0.0 - wanna check it out?
thanks

from spacetime.