As a programmer, I would never put anything except UTC or Unix time into a computer program or database. The front end can show the user whatever localized bullshit they want to see.
Most of the time, yes, but not always. Sometimes you actually need local time stored rather than UTC. Simple example: alarm clock. User wants to be waken up at 7:00. No matter if it is summer time or winter time. Even if they travels to a different time zone - still will want to be waken up in the morning. If we store this time as UTC much more unnecessary and error-prone conversions will be needed. Similar issues may arise with other calendar events.
Of course, at some point this will be converted to UTC for comparison with actual point in time.
As a programmer, I would never put anything except UTC or Unix time into a computer program or database. The front end can show the user whatever localized bullshit they want to see.
Most of the time, yes, but not always. Sometimes you actually need local time stored rather than UTC. Simple example: alarm clock. User wants to be waken up at 7:00. No matter if it is summer time or winter time. Even if they travels to a different time zone - still will want to be waken up in the morning. If we store this time as UTC much more unnecessary and error-prone conversions will be needed. Similar issues may arise with other calendar events. Of course, at some point this will be converted to UTC for comparison with actual point in time.
But if you consume data from something not in utc and need to get it there, there is still room for bugs.
I changed our systems a previous job to store all in utc and got made to put it back to jst (Japan). That was … Fun