YHK - yet another hacker news clone

Let's get rid of time!

That's not a major factor in this, afaik.

A) you need the new timezone definition available and pushed everywhere regardless. It doesn't matter what zone the RTC uses.

B) For future events, you need a way to manage what happens when the time zone they're scheduled in changes OR when they change to a new time zone. Microsoft has been terrible at this part on every time zone change I've been aware of (it's hard, but it's not this hard, and the Canadian change was published with sufficient notice, and time zone changes happen for recurring events, this is not a new requirement). But there's no connection to the time zone of the RTC here either.

If you have issues with poor behavior specifically around transitions, that could be related... Repeatedly moving forward or backward for DST is something where keeping the RTC in UTC would help.

UTC brings its own batch of problems when it comes to local time relative scenarios.

Last time I looked best practice for a real calendar app was to store in local time with time zone, not UTC with offset.

UTC is time in theory. Points in time separated by numbers of seconds. Great until the reality of time being a social construct breaks your assumptions. Still, use UTC until you are actually building a calendar app. Depending on your use case, consider storing timezone instead of offset.

  best practice for a real calendar app was to store in local time with time zone, not UTC with offset

For past events, you can certainly store them as UTC and (possibly implied) location, provided that you also have a historically accurate database of all past time zone changes, so that you do not report that a meeting took place at 9:00 when it actually happened at 10:00, but the current time zone rules (at that location) are not the same today as they were on that date in the past.

For future events, you have to store them as location + timezone-naive dates and times, a.k.a. local time. Since if a meeting at a certain location is scheduled at 9:00, which is currently at 02:00 UTC, and then a timezone change happens, and UTC 2 suddenly means 10:00 at that same future date and location, the meeting will still happen at 9:00 local time. You cannot store future events as UTC only.

They're vibecoding.

it seems an unsolvable problem either way, the meeting is "at 12:00 london"

1. the London person owns it, schedules in local (London) time 12:00

2. the London person owns it, schedules mental math explicit Alberta time 05:00

3. the Alberta person owns it, schedules in local (Alberta) mental math time 05:00

4. the Alberta person owns it, schedules in explicit London time 12:00

You cannot get all of these working by software only no matter what you do, because there "mental math" time cannot take into account the implicit expectations, 1 and 4 will be correct as stated (the meeting is at 12 London time) but 2 and 3 what do you do? How would you differentiate between "mental math what I thought Alberta time was" vs "I really meant it at this Alberta time"