Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> most applications and most people do not have to deal with that and it's a pure waste of time to add timezone handling.

If your application deals with times at hour resolution or finer, you need to handle timezones, or you will have bugs. Maybe that's ok for your programs, but it's not ok for everyone.

>Dealing with dates and times is enough of a headache without taking care of timezones and daylight saving times.

You have it exactly backwards. Dates and times are a headache because of timezones and daylight saving times. If everyone worked in UTC time, there would be no corner cases, no converting between timezones, and no half assed timezone implementations. DST causes ambiguity in converting between time representations.

> make my code harder to understand and more complex than strictly necessary to do it's job and the jobs it may reasonably be expected to do in the future

Time handling is a library problem. The problem is too many library authors think "oh, time handling is easy. I'll just whip this up", when it's really not. I've encountered bugs in the standard libraries of several programming languages and databases. When you have the API properly defined, dealing with timezones is no harder than dealing with timestamps without timezones, because the library only allows you specify things in the correct representation. Joda Time, for Java, http://joda-time.sourceforge.net/ is the only correct API I've encountered. If you're using a library that hasn't learned the same lessons as Joda, you will have bugs.



Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: