Live from Austin!

From the Wall St Journal:

 Up until two years ago, only 15 of Indiana’s 92 counties set their clocks an hour ahead in the spring and an hour back in the fall. The rest stayed on standard time all year, in part because farmers resisted the prospect of having to work an extra hour in the morning dark. But many residents came to hate falling in and out of sync with businesses and residents in neighboring states and prevailed upon the Indiana Legislature to put the entire state on daylight-saving time beginning in the spring of 2006.

Indiana’s change of heart gave University of California-Santa Barbara economics professor Matthew Kotchen and Ph.D. student Laura Grant a unique way to see how the time shift affects energy use. Using more than seven million monthly meter readings from Duke Energy Corp., covering nearly all the households in southern Indiana for three years, they were able to compare energy consumption before and after counties began observing daylight-saving time. Readings from counties that had already adopted daylight-saving time provided a control group that helped them to adjust for changes in weather from one year to the next.

Their finding: Having the entire state switch to daylight-saving time each year, rather than stay on standard time, costs Indiana households an additional $8.6 million in electricity bills. They conclude that the reduced cost of lighting in afternoons during daylight-saving time is more than offset by the higher air-conditioning costs on hot afternoons and increased heating costs on cool mornings.

“I’ve never had a paper with such a clear and unambiguous finding as this,” says Mr. Kotchen, who presented the paper at a National Bureau of Economic Research conference this month.

A 2007 study by economists Hendrik Wolff and Ryan Kellogg of the temporary extension of daylight-saving in two Australian territories for the 2000 Summer Olympics also suggested the clock change increases energy use.

So there we have it. Dicking around with the clocks twice a year and making life awkward for software developers is not only a waste of time, it’s also a waste of energy and money, at least in places where people have air conditioning in summer.

You know how DST rules for the USA have been changed this year, and every OS needs patches?

You know how Java doesn’t use the OS’s info, so you have to patch all your Java VMs separately?

Well, it turns out that Sun’s “fix” was broken, in that it changed the behavior of the (deprecated) 3-letter time zones EST, MST and HST so that they now no longer reflect daylight saving time at all.

So, chances are you need to check every Java runtime again, and maybe delete 3 files, or run the fix again with a -bc flag.

But hey, you’ve got until 1am on Sunday to fix all your production systems. No big deal, right?

While I’m on the subject of Java’s date/time handling being a confusing mess, let’s talk about a few of the other things wrong with it…

Java.util.Date represents a date/time, i.e. an instant in time.

Java.sql.Time represents a date/time as well. It is a subclass of Java.util.Date, yet you can’t cast a Date to a Time. Instead, you have to get the epoch time in milliseconds from your Date, and use that long value to construct a Time.

To get the epoch time/date from your Date, you use the getTime() method, which gives you a long rather than a Time. Java.util.Calendar also represents a date/time. It also has a getTime() method. However, that getTime() method returns a Date object, not a Time object or a long epoch time.

Next: Calendar numbers months from zero, so January is month 0, February is month 1. This makes it unlike any calendar in human history.

Next: If you read a Time value from a database, you can’t examine it (e.g. check the hour is AM or PM) until you convert it into a Calendar. You can’t do that by simply constructing a Calendar with the Time value. The only way to create a Calendar with a particular time value is to construct an empty Calendar, then call setTime(). And of course, setTime takes a Date, not a Time. So you have to convert your Time to a long, convert the long to a Date, create a Calendar, then call setTime() on the Calendar with the Date as argument.

In fact Date objects are pretty much a useless relic, almost all date and time handling is done with Calendar objects. For example, SimpleDateFormat allows you to convert String objects to and from date/time values. However, it only returns Date objects. So your String gets parsed into fields, which are then converted by Java to a Calendar-like representation, which is then converted to a Date object passed back to you; you then convert the Date object back into fields in a Calendar so you can work with it.

Still, it’s a much more enterprisey way to do things.

I’ve spent a lot of my career in the computer industry working on computer-based calendar systems and organizers of various kinds. I have learned that doing calculations involving dates is one of the most complicated common problems in software engineering. I’m starting to assemble a list of pitfalls, and things which people think are true, but actually aren’t. Here’s a current draft.

• Time zones expressed as letters (e.g. CST) are ambiguous, and hence useless.
• Time zone offsets are not always an exact number of hours.
• Both 00:00 and 24:00 are valid times (as per ISO) and refer to different moments of a given date. 00:00 is the midnight which begins the day, 24:00 is the midnight which ends it, and is also 00:00 of the next day.
• Rounding of durations isn’t obvious. People expect a duration in hours or minutes to be rounded to the nearest unit, up or down. However, they expect a duration in days to always be rounded up. Even if the event finishes after one hour of the final day, that day still counts towards the event duration.
• Minutes do not always consist of 60 seconds. Sometimes there are leap seconds. For example, 2005 will have a leap second on December 31st 2005. So, when counting down the new year, remember that 2005-12-31 24:00:00 is actually part of 2005. I’m betting the media will get it wrong, just like they got the millennium wrong…
• Leap years. February. Get it right, OK?

• Time stamps should never be given in local time unless you also specify the time zone for every single time stamp. Otherwise, your timestamps are ambiguous for the hour which recurs when people switch back from daylight savings time to standard time. Consider the following sequence:

  Oct 31 01:55 Log in from 192.168.0.1
  Oct 31 02:05 Log in from 192.168.0.2

  Are these two events 10 minutes apart, or 70 minutes apart? Without the time zone information, you have no way to tell.

  Of course, the right thing to do is timestamp in UTC.

• Never store time as a number of seconds from an ‘epoch’ date.

  All of our local time zones are defined as offsets from UTC. For precision, UTC is defined by atomic clocks, whereas older time standards such as GMT were based on astronomical observations. However, UTC is kept in sync with older time standards by having leap seconds added or subtracted as necessary. Whenever UTC drifts far enough from UT1 or astronomical time, a leap second is scheduled.

  Lots of systems store the date and time as the number of seconds since (say) January 1st 1970. The problem is, the exact dates on which the leap seconds in our calendar will occur cannot be determined in advance, because they depend upon the subtly varying rotational speed of the earth. The earth’s rotation changed measurably after the 2004 tsunami in Asia, for example. Hence given a date and time in the future, there is no way to calculate how to represent it exactly as a number of seconds from an epoch moment.

  Another way of looking at it, is that if you have any epoch dates in 2006 stored in your computer, they’re now going to be off by a second because of the leap second announced for 2005, until your date and time library is updated.

  Of course, you can ignore leap seconds. But if you do, any calculation that asks for the number of seconds between two moments in time may give the wrong answer. It won’t be very wrong, just a few seconds off, but that might be wrong enough to cause a very expensive error.

• You must always store a time zone along with a date, even if the date has no associated time.

  The reason for this is simple: June 5th in Australia is not the same day as June 5th in San Jose. Specifically, June 5th in Australia is ending and everyone’s going to bed before June 5th in San Jose gets started. An event that happens on June 5th in Australia may happen on June 4th in San Jose, so you need to know the time zone of the event in order to display the date correctly to the user.

  If you don’t store a time zone, then basically there’s an implicit time zone, most likely the time zone that will be in effect on the date in question, at the location where the date is being measured. For an event, that will be the location where the event is happening. Obviously, implicit time zones aren’t very helpful for end users distant from the event in question, because they have to (a) realize without prompting that the correction has to be made and the date has to be adjusted, and (b) guess what the time zone is and how it will affect the date as seen from their time zone.

  In Notes, you’ll need to use a formula like this:

  ost := @If(StartTime = ""; @Time(9; 0; 0); @Time(StartTime)); tm := @TimeMerge(StartDate; ost; TimeZone); @If(StartTime = ""; @Date(tm); tm);

  This treats a date with no time as being basically the same as a date starting at 9am in the appropriate time zone. The choice of 9am is arbitrary and based on conventional business hours; there’s no answer which is always precisely correct.

• Automatically adjusting dates and times in a calendar is hard. People often complain because their electronic calendar gives them the wrong answer when they fly half way across the world and change time zone. They think it’s a fault in the software, and that it must be badly designed. The truth is that there is no right answer.

  Consider the following schedule:

  2004-10-10 10:00 Team conference call.
  2004-10-10 12:00 Lunch with Mike.
  2004-10-10 13:00 Conference session 2: Designing Groupware

  Suppose Mike and I fly 8 hours west. What happens? The first item on my schedule is a phone call. It happens at the same instant in universal time, no matter where I happen to be. Therefore to show me the right time, the software has to shift the displayed time by 8 hours. It might have to shift the date too, as a result.

  The second item on my calendar is going to happen at noon in whatever time zone Mike and I happen to be in as we travel. We may not even know in advance what that time zone is going to be. So the right thing for the software to do is probably not to shift the time at all.

  The third item is a physical event, but in this case the time and date are always going to be relative to the time zone in effect at the location where the event is taking place. So, the correct thing to do is almost certainly to leave the date and time alone.

  So should the software adjust the display of the dates and times in this example? The “correct” answer is “definitely yes, maybe, and definitely not”.

  One approach might be to have a flag in each event specifying whether the time and date should be corrected when the user changes time zone, or whether they should be allowed to float and effectively change. The flag could be part of the time zone field–if you specify a time zone field the date and time are adjusted, otherwise they float. I’ve never seen an electronic organizer that actually worked that way, though.

• Notes does not change the time and date of an event when you change time zone. This is a common misconception. Notes actually leaves the date and time exactly the same; it is not modified in any way. An event stored and displayed as starting at instant T, is still stored and displayed as starting at instant T. However, the way instant T is indicated depends on what time zone you are in, so it looks like a different time or date, but it actually isn’t.

  In contrast, the Palm OS date book does alter all the times and dates when you change time zones. If you change the time zone from San Jose to Australia, the system date and time will change, but all your events will be moved. If you set an alarm for a net radio show or a conference call, the alarm will probably happen at the wrong time. See immediately above for more explanation.