Schedule block shows dates 1 day in the past

[jorgeatorres]

Describe the bug

We're using the schedule block on our site, but dates inside this block appear to be 1 day in the past. For instance, our sessions are on Sept 10, 11 and 12, but the schedule block displays them as being on Sept 09, 10 and 11.
The site timezone is correctly configured.

To reproduce

Steps to reproduce the behavior:

1. Create a session post on our site with a given date.
2. Create a page using the schedule block.
3. The session will appear as if it was scheduled 1 day in the past.

Expected behavior

Session time in session posts should match what the schedule block displays.

Screenshots

• Session time meta for one of our sessions:
  
• Session as it appears on the schedule page:
  

WordCamp

https://colombia.wordcamp.org/2020/

System (please complete the following information):

• Device: Laptop
• OS: macOS 10.15.6
• Browser: Chrome
• Version: 84.0.4147.135

[ryelle]

I've been investigating this and I think it has to do with timezones, but I'm not totally sure about the logic why.

• The session times are correct when editing, and the sessions are broken into day-buckets correctly. The date passed into <ScheduleDay /> is 20200910.
• The timezone of the site is using a named zone, "America/Bogota", which is UTC-5.
• When viewed with a more positive UTC offset (-4, +1, etc), the heading is wrong, Sept 9
• When viewed with a more negative UTC offset (-6, -11), the heading is Sept 10
• The times of the sessions never change, even though they should be shown in the local (browser) time

I've switched https://colombia.wordcamp.org/2020/ to use the UTC offset directly (under Ajustes -> Generales -> Zona horaria), and that fixes everything above - the headings are correct now, and the session times are correct for the site visitor too, showing the real time of the session in their local timezone.

I think this issue comes back to flakey support for string timezones, WordPress/gutenberg#22193. Switching sites to UTC offsets is not a good long term solution, but works for now. I'm going to leave this open to track the WordCamp side of things, but it's likely date changes are needed on the WP core side.

[jorgeatorres]

@ryelle: Thanks for looking into this. I didn't think my timezone would make a difference but what you said above makes sense and explains why I was seeing "Sept 9" (as the site's UTC-5 but I'm in UTC-3). I'm glad there's at least a workaround and that switching to UTC, while not ideal, fixes the issues. 🙇

[iandunn]

WordPress/gutenberg#25078 and WordPress/gutenberg#22193 alone aren't enough to fix this. After those are installed, though, we can work around this by replacing the YYYYMMDD value with the timestamp of the first session, though. e.g.,

- { dateI18n( settings.date_format, date ) }
+ { dateI18n( settings.date_format, sessions[0].derived.startTime ) }

There's 1 other place in the function that needs a similar change, and possibly a few others throughout the block's code.

[iandunn]

Er, nevermind, I think the proper solution here is to use wp.date.format() when displaying those YYYYMMDD values, because they've already been converted to the local/site/venue timezone. Using datei18n() et al would add the offset a 2nd time, which can make it cross a date boundary.