

How Not to Write Code - fogus
http://funcall.blogspot.com/2009/08/how-not-to-write-code.html

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

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

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

~~~
kragen
_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.

~~~
calambrac
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?

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

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

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

~~~
roc
Anything that was worth writing will grow and change.

It only grows _into a monster_ if you allow yourself to write duct tape code.

~~~
mcantor
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?"

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

