It is December 1, 2019, at 12:27 AM, and I'm still struggling to calm down. This month was the last of 2019, the final month of the 2010s, and the last month before the first group of 90s-born individuals turned 30. On the very first day of this month, at exactly midnight, the code I wrote contained a bug that left me completely frustrated.

Here's what happened: our company ran a promotional event from November 1st to December 1st at midnight. To ensure all WeChat Mini Program UI elements relatted to the event were removed by 2019-12-01 00:00, I wrote the following code:

// Get the timestamp for December 1, 2019
new Date('2019-12-01').getTime() // or Date.parse('2019-12-01') returns 1575158400000
const isS11 = Date.now() < 1575158400000

All UI elements were controlled based on this isS11 boolean value. After writing the logic, I deployed it to production early. When a colleague from operations asked about it, I confidently assured them everything would work as planned.

At midnight, the boss sent a red envelope in the group chat. After grabbing it, I opened the mini program to check if the event had ended. Unfortunately, the element was still there. I tried refreshing and reopening the app, but nothing changed. I felt my face burning—this was a major embarrassment.

I immediately opened VSCode and checked the isue in the console with the following code:

What? Why is it 8 AM? Shouldn't it be midnight by default? No time to think, I adjusted the code to include hours and minutes:

const isS11 = Date.now() < Date.parse('2019-12-01 00:00')

This time it worked correctly. I quickly submitted the fix and then reviewed TC39 specifications. I found the explanation here. When the Date constructer receives a string, it uses Date.parse to get the timestamp. According to the specification:

When the UTC offset representation is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time.

In other words, when no UTC marker is present, date-only strings are treated as UTC times, while date-time strings are considered local times.

new Date('2019-12-01') // interpreted as 00:00 UTC, which is 08:00 AM Beijing Time
new Date('2019-12-01 00:00') // interpreted as 00:00 Beijing Time

We are in the UTC+8 time zone. The string '2019-12-01' was parsed as 00:00 UTC, which translates to 08:00 AM in Beijing.

Finally, I want to criticize the TC39 team for not making the parsing consistent. Otherwise, I wouldn't have fallen into this trap. Fortunately, WeChat's emergency review process was fast, and the update was approved within half an hour (a big thank you to WeChat), saving me from a major mistake.