Hacker News new | ask | show | jobs
by gergely 1900 days ago
These use cases are also "fun" if you add timezones as well into the mix!
2 comments

Even 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.

shudder

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.

Not 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.