It seems like if the TZ variable is not set in the environment, we get the
following dates output.

/var/tmp/portage/dev-util/darcs-2.0.2/work/darcs-2.0.2/tests-shell-hashed.dir/tmp_steve
Mon Oct  6 20:30:43 Local time zone must be set--see zic manual page 2008 
steve
  * Bnote

This was caught by our regression tests on Gentoo:
http://bugs.gentoo.org/show_bug.cgi?id=239368#c10

As I understand it, we are using the calenderTimeToString function to output
dates.  It would be if somebody could cook up a little test to see what it
outputs when the local timezone is not set.  Also, we could perhaps account for
this sort of situation by assuming UTC.

I'm marking this need-volunteer because it seems pretty clear what to do:
 * verify that this comes straight from calendarTimeToString
 * possibly write code to compensate

Simple date script attached

Attachments

• datenow.hs

It turned out that /etc/localtime was not set on the testing machine.
http://bugs.gentoo.org/show_bug.cgi?id=239368#c12
Once it was set, all tests passed.

Apparently even running

 $ date

breaks when it's unset (says google). Should darcs warn the user his environment
is broken? Or just do what all other applications do? :)

I don't think there's all too much we can do about this :-)

Marking not-our-bug, and resolved (since we know what the answer is).

Note that I had previously assumed that local timezone meant the TZ environment
variable, which was silly and wrong.