4 ms·

I call bullshit. As you already point out, timezones are only relevant if you have to deal with times from multiple timezones. In practice, most applications an

I call bullshit. As you already point out, timezones are only relevant if you have to deal with times from multiple timezones. In practice, most applications and most people do not have to deal with that and it's a pure waste of time to add timezone handling. Dealing with dates and times is enough of a headache without taking care of timezones and daylight saving times. I'll be damned if I 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. You're not just being pedantic: your encouraging massive overengineering.

jerf 17y ago
It's not overengineering. It's easier to deal with times with timezones (probably converting them back to epoch time, but doing so unambiguously). If you've never done date handling correctly before, you may not realize that. It only takes one place where the ambiguity bites you to make up for all the "ease" you got yourself by leaving them off, and you point out the case where the user doesn't even have to change timezones: DST. It doesn't hardly add any lines of code to get it right. It's really no different than arguing "I don't need to know about text encodings"; it's actually easier to do it right the first time than just muddle along. Text encodings and dates are hard because people just muddle along and think they're getting somewhere. Fortunately, it's a lot easier to seal away the pain with datetimes than it is with text encodings.
arohner 17y ago
> 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/ 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.

jerf 17y ago

It's not overengineering. It's easier to deal with times with timezones (probably converting them back to epoch time, but doing so unambiguously). If you've never done date handling correctly before, you may not realize that. It only takes one place where the ambiguity bites you to make up for all the "ease" you got yourself by leaving them off, and you point out the case where the user doesn't even have to change timezones: DST. It doesn't hardly add any lines of code to get it right. It's really no different than arguing "I don't need to know about text encodings"; it's actually easier to do it right the first time than just muddle along. Text encodings and dates are hard because people just muddle along and think they're getting somewhere. Fortunately, it's a lot easier to seal away the pain with datetimes than it is with text encodings.

arohner 17y ago

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