[levosmetalo]

And then your application has to schedule a recurring weekly meeting happening at exactly 9:00 CST, and suddenly, you have to update your DB schema and all code instances everywhere to actually deal with the time zones. And then you realize you'd be better off if you were just using a sane time zone library from the start instead of pretending time zones don't exist.

[WatchDog]

They are different things.

You store your datetimes/instants as UTC, you store your "every day at 9 CST" rule separate from that.

Your rule table might have a column for a cron expression, and a column for the tz database name.

Meanwhile, your table for the meeting records has the time represented as a UTC timestamp.

[phlo]

And to stay with the theme of the article: Chances are, the meeting actually _isn't_ intended to be scheduled for 9am CST, but rather 9am America/Chicago. The key difference being that Chicago only observes CST for half of the year, and most people would probably expect for their recurring meeting to happen at the same local time, regardless of the season.

If the meeting is in _the other_ CST (the Taipei one), there's good news: Taipei doesn't do daylight savings. On the flip side, Chicago attendees might dial in fourteen hours early, so Asia/Taipei is a safer bet, too.