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.

[Updated and moved to my work site.]