2 ms·
Always use UTC when storing or crossing the wire with dates. I've been setting all servers, cloud or local to UTC when I have that option for about a decade an
by tracker1 4y ago
Always use UTC when storing or crossing the wire with dates. I've been setting all servers, cloud or local to UTC when I have that option for about a decade and a half... I nearly always store dates as UTC unless there's a location attached, such as for a localized event... Doing anything else leads to heartache, despair and weird bugs.
Trying to read TZ1, convert to TZN then send to a user vs. storing as UTC, reading as UTC, and letting the client convert to/from local (far easier than other options.
- jiggawatts 4y agoThis only works for new applications or systems that will never have older applications connected to them. Databases in particular tend to have a plethora of "random stuff" talking to them and sending ad-hoc queries. Microsoft's sales reps have been running around like they're on coke telling everyone who's willing to listen to them to lift & shift legacy apps to the cloud. They have KPIs around migrations to PaaS services, so they always recommend moving applications to App Service and Azure SQL first. Customers listen, migrate their apps, and get burned like we did. Their PaaS services are crazy over-priced and have poor performance, which makes their value proposition a no-go for most newly developed apps. At the same time, they're not suitable for Enterprise users migrating old apps either.
- tracker1 4y agoCan't speak to the planning that did or didn't happen on this. That also includes and risk assessment... I would look to whoever did the risk assessment for not understanding what was happening well enough. That said, whenever I've touched a legacy app for any forward migrations... I've learned that date/time handling is usually one of the first things you should confirm. Just my own take on this.