Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
How Not to Write Code (funcall.blogspot.com)
15 points by fogus on Aug 3, 2009 | hide | past | favorite | 24 comments



There is no such thing as a time without a timezone. There is no such thing as 11:23 am. There are in fact at least 30 11:23ams on any given day.

If I was designing a datetime library, it would raise an exception if you tried to give it a time without a timezone. There would be no implicit timezones, no default arguments.

If you think this is being pedantic... you've clearly never worked with times coming from multiple timezones at once, and, as this article shows, you probably live in UTC since even within one timezone you tend to get different defaults between localtime and UTC. And everybody gets incorrectly-set machines with just-flat-wrong timezones and correspondingly skewed clocks.

If you ever parse a time without a timezone, that's a bug. If you have a time and you can't parse it because you don't know the timezone, that's a bug in whatever is emitting the time.

IMNSHO, this is right up there with "there is no such thing as a string without an encoding" in importance.


I agree with the sentiment, but there are a lot of more complicated scenarios in real-world applications. For example, most calendar apps need the concept of a "floating timezone":

I may have one item on my schedule called "nap time" with a time of 15:00 (no time zone). I want my computer to tell me to take a nap at 15:00 local time, no matter where in the world I am today. But I have another item on my schedule called "conference call with CEO" with a time of 13:30 PDT. I want that call to happen at a specific absolute time (not local time).


'For example, most calendar apps need the concept of a "floating timezone":'

Ok... but that's a timezone, too, at least from the point of view I'm talking about. It's not an ill-defined 11:00am, it's a specific 11:00am. The root problem is specifications that match more than one uniquely-defined time.


Joda time has this concept, it calls it a partial http://joda-time.sourceforge.net/key_partial.html . A partial is a datetime without a time zone, so it only partially specifies a time. You can combine a partial with a timezone to get an instant, a fully specified date time.

It's also interesting to note that some operations cannot be performed with partials. For example, you can't add an instant and a partial (because that would be buggy). In order to add them, you have to first convert the partial to an instant (by specifying a timezone). In the parent's example, nap time would be a partial of 15:00, and your calendar app would notify about nap time by specifying the current timezone of the computer.


You know, when I write down the times of meetings or flights in my paper notebook with a pencil, it doesn't give me error messages because it doesn't know what timezone they're in. Sometimes they're in Argentine time, sometimes they're in California time, sometimes they're somewhere else. Sometimes I do write down a timezone because there's the potential for confusion, and other times I don't.

Your comment is a recipe for writing software that is worse than my paper notebook, in the sense that I would prefer to use the paper notebook.


Your computer program is free to try to guess your timezone, free to store the fact that it guessed, and show you the guess, and give you a convenient UI for correcting the guess if it gets it wrong, free to offer some preferences to control the way it guesses... but it should never store a raw 11:32 (as a time, not a string) in its memory at any point in the process. That's a recipe for software worse than your paper notebook, because it tries to wake you up at 2:32 am localtime for your meeting. Oops.

But in general... computers and ambiguity don't get along. Dealing with that by writing sloppy programs is a recipe for disaster. Sounds like you're not writing down dates anyhow, just chunks of text that you don't expect a computer to interpret. If you do expect it to interpret your date you better have a specific time in mind or it's not going to do the computer any good anyhow.


free to try to guess your timezone, free to store the fact that it guessed, and show you the guess, and give you a convenient UI for correcting the guess if it gets it wrong

This is far less convenient than pencil and paper.

it tries to wake you up at 2:32 am localtime

Yes, in order to instruct the computer to do something at a particular time, you have to reduce it to absolute time (although I think this is best done by storing the local time and the time zone, rather than the absolute time, since the time zone may change between the time I write down the time and the time I use it). But there are lots of times I write down that can be usefully processed without being reduced to absolute time; for example, if I have a bunch of times in the same (unspecified) timezone, I can sort them and compute intervals between them. (...usually.)

There's a difference between writing sloppy programs and writing programs that can be successfully used sloppily.


Then just write your strings-that-represent-timelike-things in your text editor and be done with it. What, exactly, is your point? You think that because you don't need your personal strings to actually denote time, this isn't a problem that ever needs to be addressed precisely and accurately?


As I said in the comment you're replying to, there are lots of times I write down that can be usefully processed without being reduced to absolute time. My text editor doesn't know how to do that. (Much.) I'm writing here precisely because I think it's a problem that often needs to be addressed precisely and accurately, and neither automatically falsifying data on input, nor making an application that's harder to use than pencil and paper, is an acceptable solution to the problem.


Then use a better text editor.

You're doing a bad job of distinguishing between a feature you personally want in an application, and the actual problems associated with storing times. As has been pointed out, there's no such thing as a time without a timezone. '12:30', the thing you want to write, is just a string. Acting like it's more than a string in your application is fine - strings are very flexible - but that's a completely different topic than the one at hand. You don't seem to be grasping this.


I guess the challange is to enter a precise time using a computer, and make it as easy as writing an imprecise time on paper.

I don't know where to go from there. On paper, you can assume than a time without a timezone is in localtime. That is fine, since it takes effort to move paper from one timezone to another. If you know the paper is from a different timezone, you might switch your interpretation, even without the timezone stated explicilty.


Except his comment is about writing a datetime library. An application could provide reasonable defaults.


Providing a default timezone would also be worse than my paper notebook, because it would mean that some of the times I enter would be assigned to the incorrect timezone, which means they'd be assigned to the incorrect absolute time. It's a recipe for automatically falsifying data as soon as it's entered!


Then your paper notebook is also implicitly incorrect, since you have not recorded complete information anywhere.


There's a substantial difference between omitting information and writing down incorrect information. The second is much worse.


Informing application users of the defaults is easy - and in this case, the defaults are what most people would expect.


Having an implicit timezone for the current position--as iCal does, say, while still allowing you to create events in other timezones--is a UI issue, and not necessarily a bad idea. But storing or ever even computing with "times" without a timezone is meaningless.


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.


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


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.


I'm really torn by this article. Part of me wants to dispassionately bark, "They should have obeyed the Single Responsibility Principle and the Open/Closed Principle from the start!" and coldly click on to the next link that tickles my fancy. But another part of me feels an inexplicable sympathy for the original developers here. Everyone has worked on that one app or library that organically evolved into a monster.

I almost feel like it's impossible to "judge" what happened as described by the author without understanding more context: How brutal were the requirements changes? Could they have been predicted? How much was the app designed before that fateful first revision was written?

I think this also has to do with the framework or language being used. If the app was written in Python, maybe it would have been less ridiculous to create an explicit "fix our stupid mistake" TimeDelta and pass it around. I definitely think that someone, at some point, should have had the sense to take a step back and say, "Maybe we shouldn't be fixing this by manually modifying the second count and checking for DST edge cases." The libraries exist for a reason, but without knowing which one they were working with, one can't really say definitively what they "should" have done.

In summary, it sucks that the author FTA has to deal with this date/time kluge that he didn't create, but... that's software development.


Anything that was worth writing will grow and change.

It only grows into a monster if you allow yourself to write duct tape code.


I was meaning to imply more than I did by saying "organic". IMHO, "organic" growth spells disaster for a codebase, because it means (to me, specifically) growing without conscious curation on the part of the developers. I should have explained myself fully instead of using such a loaded word; it seems that the only question these developers asked was "How do I make this new feature work?" instead of "How does this new feature change the silhouette of my application?"


You try and cut corners, it'll come bite you sometimes. Oh no, not every time -- then you'd learn your lesson. But sometimes.




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: