3 ms·
Time is two different things. Just making everything UTC until display time is incompatible with that. Sometimes you need to operate on calendar units or clock
by happytoexplain 3y ago
Time is two different things. Just making everything UTC until display time is incompatible with that. Sometimes you need to operate on calendar units or clock units as part of business logic.
- worik 3y ago> Sometimes you need to operate on calendar units or clock units as part of business logic. And you must do it in UTC
- erik_seaberg 3y agoTo make something happen at 9 AM every day in the user’s time zone, choosing UTC will make it harder.
- worik 3y agoNeeds must. But otherwise use UTC A local time aware process has to be available for users. Of course But in the backend it is UTC Storing time any other way is a world of pain
- Dylan16807 3y ago> But in the backend it is UTC Scenario 1: You have an event to schedule at 9am local at some future date. You want to convert to UTC. But you can only do that if you know the offset, and the offset for future dates can change or be unknown. How do you resolve this? Scenario 2: Now the event is "9am every day, indefinitely". How do you represent that as UTC? Do you generate tens of thousands of separate timestamps?