ctm
commented
6 months ago The current code is written a way that superficially looks like it should already do the right thing. I will have to poke around to figure out what's going on.
Here's where we compute tomorrow's time in UTC:
fn tomorrows_start_at(start_at: &DateTime<Utc>) -> Option<DateTime<Utc>> {
let pacific_start_at = start_at.with_timezone(&Pacific);
let tomorrow = pacific_start_at.date_naive().succ_opt().unwrap();
let time = pacific_start_at.time();
NaiveDateTime::new(tomorrow, time)
.and_local_timezone(Pacific)
.earliest()
.map(|pacific| pacific.with_timezone(&Utc))
}Since that code is in front-ends/web, it gets compiled to web assembly and adding a test to it is much trickier than if it were to live somewhere that gets compiled both natively and to web assembly (e.g. lib/commands), so it probably makes sense to move that code. However, I can iterate much faster if I create a throw-away crate completely outside of mb2.
See whether the code mb2 uses to schedule the next day's event doesn't handle the switch to DST and fix it if it doesn't.
ADB DaVoice scheduled today's event an hour later than it should be. He was the winner of yesterday's event. My guess is the code mb2 uses to schedule the event does a naive addition of 24 hours, rather than a timezone aware increment of the day. If so, fix it.
This only happens twice a year, but it's trivial to fix, especially since I've taken to using Pacific as the reference time zone. My guess is when I wrote the code to advance it a day I used the faulty logic that there's no "universal" solution in the US, much less International space, since, Arizona doesn't switch. Although that's true, the vast majority of current players are in the US in locations that do switch on and off Daylight Saving Time and Las Vegas is in Pacific and that's where the World Series of Poker is located. As such, I'm adding the
WSOPSlabel, even though the World Series of Poker is held exclusively during Daylight Saving Time.