I wrote some months ago about the mis-guided initiative to change Daylight Saving Time yet again. As it turns out, the law was quietly passed about a month ago. I've been recently looking at the impact and what software I have that will require changing to avoid any troubles next year when it goes into effect.

It doesn't help that the law has built-into it a review by the Energy Commission. The outcome of this review may in fact negate or void the law. You ever tried to code something like that into software? Yarghhh.

Those folks who produce software which uses Daylight Saving calculations are stuck between a rock and a hard place. They must scramble now to ensure their products conform and have time to be deployed before the change occurs. But if the Energy Commission review voids the law, they are left scrambling once again - and little time to deploy.

Your operating system will require upgrading. This isn't much of a problem for Windows XP folks, since live updates are built-in (assuming you have the service turned on). For Linux, it's a bit more problematic. I have no idea if my service providor in Los Angeles plans to upgrade, so my websites may report the wrong time for several weeks. There's nothing I can do to fix it, except to check the time and see if the timezone rules were properly applied or not for those few weeks.

Talk about wasted code...

But were you aware that DST is not practiced in Arizona? (Hawaii as well, but that's far removed from the standard four US time zones and usually has its own field in software forms). Does your timezone setting software ask if you live in Arizona? Ah, but the Navajo Nation observes DST, even in Arizona. Does your timezone setting software ever ask you if you are part of the Navajo Nation? Mine doesn't.

The madness continues...

You thought we had crazy DST laws! Australia changes Daylight Saving anytime somebody throws a wild party; which means the start and stop time changes constantly. Some cities have their own rules. Can you imagine if we had to have a different DST rule for Sunnyvale or San Francisco during Carnaval? Folks who write DST aware software can't keep up. At AOL, we finally gave up an oz. Just provide a field to let somebody change the GMT offset whenever they noticed the time wasn't the same as what the clock said. 

We've got a fresh group of brand-new spammers sending us stuff. How do I know? Today close to half of my daily spam was source code. Things like

From: {%x} 

Subject: {%rand_string}

 

Those aren't actual examples from today. I'm using them for illustration. I see about twenty different spam packages at work today and the code changes, but the concept doesn't.

What you see here are what we call 'variables' in the software world. Things like {%rand_string} are supposed to get replaced while the message is further processed. Let me guess - this one would be replaced with a random string of characters.

Spam software is just like any other software - and has by definition grown more complicated over time. There are setup and configuration files which need to be tweaked to make everything work right before Mr. Spammer ever sends out a message. If we, the recipients, are seeing lots of raw unprocessed variables that haven't been replaced, it indicates that this particular software package wasn't installed and configured correctly. If there's a large number of unconfigured or mis-configured spam software packages sending you mail, that indicates we've probably got a lot of newbies at work. Or several of the spam software packages just had a major upgrade. (It isn't just one package, because the variables are written differently in most cases). I don't have the answer. Just the observation.

I think the most interesting and amusing of the subject line generators is the one that goes 'Your {noun}, {adverb} {verb}'. I know you've seen them: Your pudding, easily running. Your future, quickly fishing. That kind of thing...