August 16th, 2024

The 1 Hour per Year Bug (But Only in Pacific Time!)

A bug in Google Docs on November 8, 2021, caused incorrect timestamps for comments made late on November 7 due to daylight saving time changes, affecting Pacific Time Zone users.

Read original articleLink Icon
The 1 Hour per Year Bug (But Only in Pacific Time!)

On November 8, 2021, a bug was discovered in Google Docs that affected users in the Pacific Time Zone (PT) during the transition out of daylight saving time. Users reported that comments and replies were timestamped as being created "tomorrow" when they were made between 11:00 PM and 11:59 PM PT on November 7. The issue arose because the code used to calculate the time difference did not account for the change in time zones that occurred when daylight saving time ended. Specifically, the code compared the current time in Pacific Daylight Time (PDT) with input times in Pacific Standard Time (PST), leading to an incorrect calculation of 24 hours instead of 23. The bug was fixed by utilizing JavaScript's Date class to correctly compute the time zone offsets, ensuring accurate time calculations. Interestingly, this bug also had implications when daylight saving time began, but it never manifested in Google Docs since users cannot create future comments. Ultimately, this bug was unique to the Pacific Time Zone, occurring only for one hour each year due to the specific timing of daylight saving changes.

- A bug in Google Docs caused timestamps to incorrectly show "tomorrow" for comments made late on November 7, 2021.

- The issue was linked to the transition from daylight saving time, affecting users in the Pacific Time Zone.

- The bug was fixed by adjusting the code to account for time zone differences.

- This bug was unique to the Pacific Time Zone, occurring only for one hour each year.

- The fix has been in place since August 2024, ensuring accurate timestamping for users.

Related

Google Docs adding Markdown import and export

Google Docs adding Markdown import and export

Google Docs introduces new Markdown features for enhanced interoperability with other tools. Users can convert content between Markdown and Docs formats, benefiting technical writers for software documentation collaboration. Available for Google Workspace and personal accounts.

Import and Export Markdown in Google Docs

Import and Export Markdown in Google Docs

Google Workspace introduces Markdown import and export in Google Docs, enhancing compatibility with Markdown tools. Users can convert content, collaborate on software documentation, and streamline workflows. Admins lack control, and rollout spans 15 days from July 16, 2024.

Real, actual Markdown support is arriving in Google Docs

Real, actual Markdown support is arriving in Google Docs

Google Docs now supports Markdown, enhancing writing for technical users. Seamless conversion between Markdown and Docs formatting simplifies collaboration and content creation across platforms. Users can soon access this feature in the Tools menu.

Storing UTC is not a silver bullet (2019)

Storing UTC is not a silver bullet (2019)

Storing events in UTC is a common practice, but Jon Skeet's blog challenges this notion due to EU time zone rule changes. Options include permanent UTC storage, UTC conversion with adjustments, and preserving local time while deriving UTC for convenience. The blog stresses the complexity of handling time zone data in applications, advocating for a strategy that prioritizes local time preservation with UTC for ordering and countdown.

Google Says Sorry After Passwords Vanish for 15M Windows User

Google Says Sorry After Passwords Vanish for 15M Windows User

Google apologized for a bug that caused passwords to disappear for 15 million Chrome users. The issue lasted 18 hours, affecting 2% of users, and was resolved with a browser restart.

Link Icon 14 comments
By @Moru - 4 months
Can we talk about all the problems with dates formated as "today", "tomorrow" or "2 hours ago" when trying to figure out how far apport two log-events happened? I at least want an OPTION to set that I want all dates down to the second exactly when they happened... And in a standard format with Y-M-D H:m:s that can sort naturally. The most significant part first, the least significant last.
By @mjtardiff - 4 months
Keep time and calculate intervals in epoch time, for sure. But the DST/ST switch happens at 02:00 local time on the date of the switch (always a Sunday morning in the US), and so since the OP points out that the bug only happens when DST switches at 23:00 PT…that’s why. The code was doing time-switching wrong in all zones.

But as another poster points out, when a server lives in one time zone and is used in another, all hell can easily break loose when deciding what to show the local user.

By @crote - 4 months
It does make me wonder how many bugs like these exist in the average codebase. In this case there was an "unusually large" amount of reports, all coming from the same timezone, all filed at the same time.

But imagine getting a single bug report, which doesn't provide a timezone or timestamp and essentially boils down to "I swear it said the wrong date yesterday but it fixed itself!": how much time are you really going to spend trying to reproduce it before closing it with the conclusion that the user was probably just imagining things?

By @mattbillenstein - 4 months
Clocks roll back at 2am Pacific time just like everywhere else - so the author's explanation seems unsatisfying although I've encountered this type of bug before.
By @ajennings - 4 months
This reminds me of a bug I created where the calendar showed only 30 days in March. I took the number of hours in the month, divided by 24, and rounded down.

The bigger problem was that I couldn't replicate it because I was in Arizona (which doesn't observe DST). Only users outside of Arizona were seeing the bug.

By @et-al - 4 months
> Normally I would have dismissed that as a coincidence, but daylight saving time also ended at 11:00pm (PT) on November 7!

Huh? Unless I'm mistaken, Daylight Saving ended at 2am local time on Nov 7, 2021.

Was the bug that Day Saving is internally set based on Eastern Time (i.e. 2am ET / 11pm PT)?

By @yuliyp - 4 months
My favorite DST bug was a system that was supposed to run every few seconds taking a nap for an hour. It was an event loop thingy that had a few different types of tasks it might do. When it finished one of those tasks it'd record (in time-zone-local time) the time it completed it. When the event loop ran, it'd check that timestamp against now to see whether the task needed doing.

In comes the DST rollback. At 1:59 AM Pacific Daylight time the task ran. At 2:00 AM Pacific Daylight time the time changes to 1:00 AM Pacific Standard time. For the next hour it just sees "ooh 1:01 AM is not more than 1 minutes after 1:59 AM, I'm going to sleep. 1:02 AM is not more than 1 minute after 1:59 AM..." and ends up falling behind for that hour until it magically fixes itself at 2:01 AM Pacific Standard Time

By @tomeraberbach - 4 months
Hey folks! I appreciate all the comments. Some of them made me realize I had some mistakes in the article. I went ahead and updated some of the content, and also added some notes explaining what I changed. Thanks for the feedback :)
By @mulmen - 4 months
I’m having a hard time following how such naive time handling became part of a Google product. Pick an epoch for timekeeping. Timezones are a display issue.
By @jakub_g - 4 months
I once came across a similar bug in a popular JS lib, only in Russian timezones, only in some browsers, only on Windows. (It happened due to Russia changing their timezones).

https://github.com/yui/yui2/pull/15

By @kinderjaje - 4 months
Wow, that’s a tricky bug! Time zones can be so confusing. Glad you figured it out and fixed it. Do you think this could happen in other time zones too?
By @iwontberude - 4 months
> It formats the time as “tomorrow”… [clown emoji]

Unnecessarily negative IMHO to implicitly call the person who came before you a clown, especially for a bug which is so trivial.

By @sixthDot - 4 months
Anyway, kill the DST with fire.
By @jbrot - 4 months
The article claims that the daylight savings transition happens at 11pm in pacific time. However, my understanding is that this transition should happen at 2 am for all us time zones. Where is 11pm coming from?