If I create a meeting for next November at 1600 local time in paris, and it's stored at 1500 UTC, what happens if France decides to stick with summer time between now and then. The meeting is still 1600 Paris, but the time will be 1400 UTC.
Similarly if I want a task to run at 6AM local time every day
If a time is in the future you usually want to store it as local time because we don't know what the offset between local and UTC will be.
Re:Breaking our Latin-1 assumptions (2017)
by throwaway290 on Sunday June 19, 2022 @07:00AM
(#31798196)
For some purposes concerning local future event scheduling you are right that it may be necessary to store date-time representation with timezone (or location, if it's possible to reliably infer timezone from location) and calendar (if non-Gregorian) rather than absolute UTC stamp. Not sure how common such cases are, compared with recording timestamps of past events.
Re:Breaking our Latin-1 assumptions (2017)
by jiggawatts on Sunday June 19, 2022 @12:29AM
(#31796174)
If you’re developing a database engine from scratch with no attempt at backwards compatibility with anything, then maybe you can get away with that. But there’s three decades worth of Microsoft SQL client applications that assume that GETDATE and GETUTCDATE do different things.
Microsoft just decided to pretend that globalisation is not a problem, but proceeded to market this platform to foreign enterprises as a good migration target for legacy databases and associated applications.
So I think you underestimate the sheer scope and bloat needed to accommodate all possible languages and cultures equally well. And if we abandon that idea, perhaps it makes sense to keep things simple and support customization instead. If on the other hand Azure doesn't even allow installing any non-English FTS engine that would be questionable of course.