Ref T11326. Normally, events occur at a specific epoch, independent of the viewer. For example, if we're having a meeting in 35 hours, every user who looks at the event will see that it starts 35 hours from now.

But when an event is "All Day", the start time and end time depend on the viewer. A day like "Christmas" does not start at the same time for everyone: it starts sooner if you're in a more-eastern timezone. Baiscally, an event on "July 15th" starts whenever "July 15th" starts for whoever is looking at it.

Previously, we stored these events by using the western-most and eastern-most timezones as the start and end times (the earliest possible start and latest possible end).

This worked OK, but we get into a bunch of trouble with EditEngine, mostly because each field can be updated individually now. We can't easily tell if an event is all-day or not when reading or updating the start time and end time, and making that easier would introduce a huge amount of complexity.

Instead, when we update the start or end time, we write two times:

• The epoch timestamp of the time the user entered, which is the start time we will use if the event is a normal event.
• The epoch timestamp of 12:00 AM in UTC on the same date as the local date the user entered. This is pretty much like just storing the date the user actually typed. This is what w'ell use if the event is an all-day event.

Then, no matter whether the event is later made all-day or not, we have all the information we need to display it correctly.

• Created and edited all-day events.
• Migrated existing all-day events, which appeared to survive without problems. (Note that events all-day which were created or edited in the last couple of days master won't survive this mutation correctly and will need to be fixed.)
• Created and edited normal, recurring, and recurring all-day events.
• Swapped back to stable, created an event, specifically migrated it forward, made sure it survived with times intact.