3 ms·
These use cases are also "fun" if you add timezones as well into the mix!
by gergely 6y ago
These use cases are also "fun" if you add timezones as well into the mix!
- deckard1 6y agoshudder I can only imagine needing to toss in standard/daylight timezone switch in there. Billing code really is the pinnacle of developer pain. It mixes the arbitrariness of special case business and customer rules with the absolute horror of time and date math.
- pc86 6y agoNot only that but in T-SQL, `AT TIME ZONE` takes DST into account but not in the names. So something like: SELECT CreatedDate AT TIME ZONE 'UTC' AT TIME ZONE 'Eastern Standard Time' FROM MyTable would in fact return `CreatedDate` at Eastern Daylight Time if executed today.
- Falkon1313 6y agoEven more fun: You use the standard datetime libraries so you don't have to deal with all that complexity. Only, they automagically muck with the data, including irrelevant precision, such as time and timezone and daylight savings time for a calendar date. And for the sake of completeness, your application allows the customer to specify a default timezone (usually that of their headquarters or something) and individual users to specify their own (useful if they work remote or in another office or something). So now you have your database's timezone (and datetime handling), your server's timezone, your application's timezone (and datetime library handling), the customer's configured timezone, the user's configured timezone, their client's own timezone handling (which may be different if they're on a business trip in a different location), all screwing with the date of something that shouldn't even have a time, timezone, or daylight savings in the first place. That's an endless whack-a-mole of bugs. And trying to just use UTC everywhere possible only gets you so far.