We've all lived with one set of Daylight Saving Time rules since about 1986. For the last twenty years it's been "First Sunday in April" and "last Sunday in October". Now, with thanks apparently due to a U.S. Congress that felt the need to 'do something', all the rest of us have to do something with our clocks.
First, though - this only matters if you actually need to worry about what time of day it is. If your lifestyle is one that doesn't revolve around a clock, then count yourself lucky and go back to your nap. Rise with the sun, and go about your day.
For the rest of us, the new rule is "second Sunday in March" and "first Sunday in November". Sunday, March 11 will be the first time this new rule is used. The usual Daylight Savings changes apply - adjust the clocks, reset your watch. As you have probably noticed by now, many more devices now come with a clock built in. Our kitchen sports no less than seven clocks.
With the new rules, there are some new adjustments. I'll run through some of the simpler changes first, then save the big ones for the end.
The rest of the world isn't making the same changes as North America. Of course, the rest of the world didn't always use the same timezone rules in the first place. Those of you making weekly calls from North America to Europe figured that one out a long time ago.
Built-In Clocks
First, pay a little extra attention your VCR. If you either use the VCR clock just by looking at it, or if you depend on it to record programs, then you will want to be sure the clock is correct. Of course, if you don't care, then skip ahead. Most VCRs receive both time and DST information from a local station, but there is no good way to ensure that the whole clock system is operating correctly. Because the DST rules have not changed for so long, it's possible that your VCR is locked into using only the old rules. On March 11, you will want to check to make sure it changes properly, and on April 1, you will want to check to ensure it doesn't change at all. A note for the future; if you have problems this spring, you will likely have problems during the first week of November as well, and the problems will recur every year in both spring and fall. If that's the case, you may be farther ahead exploring the menus on your VCR and figuring out how to turn off the DST feature altogether; then you can just reset the clock like all the other clocks in your house.
Higher end devices - your TiVo or any other personal video recorder connected to the outside world - are more akin to networked computers than VCRs, and it is very likely that they are automatically updated. Either way, make a note to check the VCR clock both on March 11 AND April 1, to ensure it is both correct the first time and that it doesn't make an extra adjustment for you on April 1. The also applies to most newer cell phones, which get their time from the cell phone network.
Clocks in Computers
Since 1986, there has been an enormous change in the use of computers in our world. Even in 1986, some computers still needed their clock set every time you started them. Today, most computers keep a reasonably accurate clock running full time, and it's not unusual to have this clock corrected against an external source. But all this hides a nasty secret, hidden from most computer users. When your computer sets the clock against an external source, it sets "universal time", once known as Greenwich Time. This is always the same, and the dirty secret is that converting Universal time to local time is entirely the job of your local computer. It needs to know all the timezone rules - the Eastern time zone is five hours behind Universal Time - and what dates are used to convert to and from Daylight Savings Time. And because computers are used everywhere, most computers need to know the timezone and DST rules for all places in the world. The computer in front of me knows 88 different places. However, various cities, states, provinces, organizations, and other parts of the world sometimes have their own ideas about local clocks and DST; one commonly used source of such data lists 390 zones around the world.
So, if you want your computer to change to Daylight Savings at the right point in time, you will need to update all those rules. If you do anything as simple as send email from your computer, those rules should be updated. (I'm talking about YOUR computer. If this is your employers computer, they have to fix it. More about why later.) Fortunately, this isn't too hard. There are easily usable patches for most computers, even older ones, as well as for most handheld computers. I'll include some links at the bottom.
The Clock Meets The Calendar
This would almost be easy, except for one additional requirement we place on many of these computers. We expect them to accurately calculate time not just right now, but well into the future. We use calendar programs to plan out our days, into next week, next month, and next year. Suddenly, this becomes an incredibly complex problem, something to make your brain hurt when you try and figure it all out. I could write several more articles about why this has become such a tricky problem - and I'm certain someone already has written such articles - but the core of the problem is this: most calendar programs, when asked to record a meeting on Mar 12, 2007 from 9AM to 10AM, first add other information such as your timezone and timezone rules, and then convert all the dates and times to a single format - typically some form of Universal Time. Whenever you ask to see your calendar, it then reverses those steps to show you your meetings and appointments.
This would all be fine, until those rules change. International travelers who carry their laptop and change to local time have long been aware of the mayhem that can happen in their calendar programs when they change the local timezone on their computer. And these DST rule changes are exactly the type of thing to cause this problem to appear for almost everyone. When your calendar program stored "9AM" it converted it to "14:00" using the Eastern time zone rule. But rule has now changed for March 12, so when it shows you the meeting, it will now show you "10AM".
There are further problems if someone creating a meeting has one version of rules for a timezone while the person accepting the meeting has a different version of the same rules. That's why you should let your local information technology department work out this problem on your work computers. They might still get it wrong - but there is no way for you to get it right.
There ARE fixes for this, but this starts to get very tricky, very quickly. The fixes often need to make changes to your appointment schedule. If the fix isn't done carefully, it may cause appointments to move more than once. In some cases, there is no correct fix available. If you have a phone call on March 12 from London (UK) at 9AM, it will be 2PM in London. After all the changes are worked out, they will still call you at 2PM London time - but that will now be 10AM Eastern time. If you have another meeting at 10AM, then the change in rules has effectively created a scheduling conflict where one previously did not exist.
This type of problem is what separates this change from the Y2K problem. With Y2K, there was little doubt about what constituted the correct result. But with timezone rule changes, there won't always be a right answer.
In some cases, we are discovering that some software can't be updated easily. Some calendar systems have add-on components to manage rooms and other resources within a company. There may be no way to update this software's existing bookings. When that happens, the only choices are to leave the bookings as-is, meaning they appear to move in time when we change the DST rules, or to erase everything and let your users rebook all their meetings and resources for the affected time period.
How Not to Do This Again
So how did we got into this situation, and how can we avoid it in the future? This is not just idle speculation; the same act of U.S. Congress that started this also sets that it runs for three years, after which time it should be evaluated to see if they will stick with it, or revert back to the old schedule. Fun times ahead!
Most of our devices that try to understand Daylight Savings Time assume that the rules will be the same every year. This assumption is the first problem. There are systems that allow you to specify timezone rules as being different from year to year. The people using those systems made all these changes back in 2005, while those of us without them had to wait until at least late November 2006 to make these changes. Designing with the assumption that the rules will change would be a start.
The calendaring issues are somewhat different. Calendar programs generally assume they know more about time than they really do. When you made that meeting for 9AM on March 12, you didn't really mean either "Eastern Standard Time" or "Eastern Daylight Time"; you likely meant "Eastern Time", expecting to use either Standard or Daylight, whichever was in use on that day. Calendaring programs also commonly assume that an 'all day' appointment means "from midnight, to midnight". But that isn't what we want it to mean. When I say "all day on March 12", then I'm usually only looking at the calendar, not the clock. It should only start at "midnight at the start of March 12" if I actually make the effort to say exactly that. Finally, calendar programs have to avoid converting everything to Universal Time and discarding information that was only available when the appointment was created.
These Daylight Savings issues don't have the same potential for large scale problems as the Y2K issues. At the same time, there may be a great many smaller issues. Y2K could have been a mess, but we sorted out all the issues early, and anything that needed fixing was fixed. This time around, we didn't really get to it early, many of the problems don't have the clear solution of Y2K, and for some problems, there just won't be a fix.
Daylight Saving Links
Microsoft Windows and applications DST changes
-
http://support.microsoft.com/gp/cp_dst
Apple Macintosh DST changes
-
http://docs.info.apple.com/article.html?artnum=305056
Blackberry DST changes
-
http://www.blackberry.com/DST2007/patch/index2.shtml
Palm DST changes
-
http://www.palm.com/us/support/downloads/dst.html
A handy test of the Java environment in your browser
-
http://ablogofideas.net/blog/2007/02/24
A good under-the-hood explanation of Daylight Saving issues
-
http://msexchangeteam.com/archive/2006/10/17/429210.aspx
This one's for Chris, still looking for that perfect rotary phone...
I'm just old enough to remember telephone exchanges. When I was a tot, phone numbers began with a two-letter EXchange code (mine was AL, for ALpine) and we always began our number "AL5" rather than "255".
Today, I came across the Telephone EXchange Name Project, a way-cool way for we ageing boomers to get our retro rocks off. Thanks to the site's mammoth database, I now know that our current phoneEX is HOward. Next time I have a batch of biz cards printed, I'm gonna use the old-fashioned phone number style.
Catchy title, that. Of course, I don't think they know they've done this.
By now, most people who are reading this have seen some reference to Matt Blaze's paper on decoding master key lock systems. An article in the New York Times will provide that kind of deep coverage. He's done a nice thing there - he's taken the rigor and planning that would normally be applied to analyzing a computer-based security system, and used it to analyze a physical security system instead.
It turns out that you can go the other way, too.
This is an idea that's been flipping around in my head for some time, but the arrival of this issue on the scene makes it an ideal time to release it into the great big world. And, as with Matt Blaze's attack, it may not even be a new idea - others may have had the same thoughts. The core of the idea is so simple that I'm certain other people have started down this path before. However, to simplify my job here, you need some basic understanding of how locks work. Matt Blaze's paper is a good start, so go scan through it.
As you read Matt Blaze's paper, at several points he describes how a key is cut by using a sequence of numbers representing the depths of the cut. "11111" represents a 5 pin key, all with the same cut depth. "44444" is a different key. For a locksmith using a standardized notation, that 'number' is the critical piece of information needed to turn a key blank into a working key. Given a working key, it is also possible to determine what number would describe the key - there is a one-to-one relationship between numbers and keys.
So, the keys are like passwords. Your lock is a mechanism for testing your password.
Now, I don't want to just protect doors. I also want to protect - for example -online music files. So here is what I will do. I wll build a device that connects to my computer, and has what looks like a lock in the front. But it functions a little differently - when you insert the key and turn it, the device measures the key cuts, and determines the "number" (see above) corresponding to that key. This number is then sent to the computer. Special software at the computer takes that number, and uses it to enable access to otherwise unavailable files. If you register your key with - for example - a music service, then you could download files that only you, with your key, can play back.
This has some nice effects - just insert my key, and the computer enables access to all my files and applications. Other people with different keys can use the same machine, and our files are separate and secure. Now, you could do this more cheaply using a USB key, for example, or using one of several dongle-style systems available for exactly this purpose. But my system still has a couple of advantages. Metal keys are very robust - they can be dropped in water, microwaved, crashed against other keys, and they will continue to work just fine. They're convenient, since most people already carry a key-ring. They don't need batteries. They're even immune to EMP attacks. Try THAT with a smartcard!
But that's not the big advantage. In fact, the big advantage is likely something that most of you are considering to be a disadvantage. You may be pointing out that all I have to do is go down to the hardware store, and they will copy the key for me. Then I can give copies of all those music files to a friend along with the key. And you would be correct - for now.
See, in use, the key system seems reasonably effective. It's not perfect - but nothing is in this domain. And since I'm using it to protect against the illicit disemination of copyrighted materials, I have a great big stick to back me up - the DMCA. And using the DMCA, I can insist that the hardware store not copy keys. Furthermore, I can insist that manufacturers of key-copying equipment no longer manufacture or sell such equipment. And if they continue, I can get them charged with a criminal offence.
Now, think about the arguments against this line of reasoning. First one - they've been doing this for years, and it was never illegal before. True - but the DMCA is a new law, creating new offences. It has to be this way, otherwise all the ways of breaking into digital files from before 1998 would remain legal. Note that the key is not simply "throwing a switch" somewhere - copying the key actually copies the "key value". There is no way to copy a key without doing that. They might argue that this is hardware, not computer stuff. Sorry, that can't be OK either, because the DMCA refers to 'devices', which the key copying machine certainly is. They may state that there are legitimate uses for the key copying machine - which is true, but isn't a defence under the DMCA (think Elcomsoft). And that's another one - the Elcomsoft trial means that such devices are allowable. My rough not-a-lawyer reading of the decision says "no" - Elcomsoft was not guilty because they didn't really understand that they were breaking the law - and once they had that explained to them, they stopped selling the offending item.
In fact, this device could be highly useful in a world where key copying is outright illegal. If they defend themselves in court, your argument is roughly as follows - my device protects files from copying, just like many other things in the marketplace. Those things are from companies who are my competition, and THEY have the DMCA to help protect their business. I simply want a level playing field, and the question of whether this key-copying equipment is ok is not the most important question. Of more importance is the idea that if the DMCA is to stand as a law, then it must apply equally, even if some companies can no longer sell certain devices.
Again - not-a-lawyer here, but I think you have more than a good chance of succeeding in one of two ways.
You may get an Elcomsoft style result - the company isn't guilty, but the key-copiers are off the market. Or they just take them off the market, and it never goes to court. Either way, you have one rather irate company, with employees, whose chief executive calls up his Congressman and asks what the hell is going on in Washington that they passed a law to put his company-of-three-decades out of business. Meanwhile, we can go back to the drawing board, and find another real-world security mechanism to target under the DMCA. I'm reasonably confident that drafting a law to allow physical key-copiers without also allowing software key-copiers can't work. The determining factor might be the "physical access" argument, which provides a DMCA exemption if the copier is only providing physical access. In that case, I'll write another article, explaining how to use some common software protection mechanism to lock my front door, and how the software (from Elcomsoft, perhaps?) is only needed to give me "physical access".
Your other outcome is a kick to the DMCA, where a judge looks at it and says (by the way, I-am-not-a-judge, either) all your arguments are correct, but the result is silly - reductio ad absurdum, the law must be bad. You'll still have to wade through the appeals, though.
So that's my idea. I can see any number of ways to implementing it - little levers whose level is read using mouse-ball optical encoders to determine the key depths. Or a small optical scanner that reads the outline of the key and determines cut depths that way. And I would add an intermediate layer of software to transform raw "key values" into "file key values" so that I can copyright my software and protect my device in the marketplace for my lifetime plus 70 years.
But I can be VERY generous on licensing terms...
Both the Toronto Star and the Globe and Mail are carrying articles today on Bell Canada's new hotspot offering, AccessZone. (Here's the press release). This is certainly the first major hotspot announcement in Canada, and it is also unusual in that it comes from a cellular carrier.
The idea of WiFi hotspots is gathering considerable momentum, although key items - such as charges - remain unresolved. But that's ok, for now. A three-month trial will help Bell determine just how many people want this as a service, which is a critical factor for future business decisions for them.
But a far more interesting question surrounds the effects that WiFi may have on 3G - the high speed cellular services. It's often claimed that 3G will offer drastically improved bandwidth, and it's left as an implication that this will resolve all problems.
But connectivity has never been that simple...
The first constraint on 3G is going to be handsets, accessories, and data package prices. By the time a consumer has outfitted themselves for high-speed services, they are spending some major cash, both upfront and per-month. For the same cash, they can get themselves a high-speed home hookup, wireless gateway, and WiFi cards for both the laptop and the handheld - and still have some money left over for POCS (Plain Old Cellular Service), which will work just about everywhere. Add in hotspots, and suddenly the WiFi option looks like a really good deal. It even delivers home networking as part of the bargain.
The second constraint is that 3G only works where carriers set it up. This is fine in urban areas, but rural areas are likely to be poorly served at first. If history is anything to go by, they could be still on analog for some time. Unfortunately, your phone is still expensive even when the data coverage isn't there.
Of course, WiFi isn't everywhere either - but that fits users' expectations. Cellular users expect their phone to work everywhere, while WiFi users - even when they are the same people - understand that coverage is not automatic. This could be seen as a real problem for the perception of 3G services. So why would a cellular provider like Bell actively promote WiFi, and even provide services?
Money. Money-money-money. Setting up a few WiFi hotspots in important places is no where near as costly as rolling out widespread 3G coverage. More importantly, WiFi looks to be a far more cost-effective way to meet the customers' expectations with regard to data services, speed, and coverage. Meanwhile, Bell can concentrate on ensuring that its cellular network delivers voice calls over as broad a region as possible - possibly even without 3G.
This isn't going to be a rosy forecast for those who want a one-device does all Treo-or-Blackberry-like solution. But it looks like an effective way to get more services to more people for less money, and that is always nice.
I'm not one of those slaves to the bean, nosir. No caffeine junky me. Though in the spirit of honesty I suppose I should mention that I have been known to slam back a diet cola or two while waiting for the first pot of the day to finish brewing.
The Tuesday Night Shredding Bee was discussing coffee ads this week, and we couldn't remember when, exactly, the "Coffee Achievers" ads ran. In trying to find out, I came across an interesting perspective on the recent history of coffee retail in North America. There is no aspect of human nature that somebody hasn't tried to stuff into a vending machine, incidentally.
I'm sort of surprised that our discussion of the CA ads didn't bring up the campaigns run by Taster's Choice in the '80s (UK) and early '90s (NA). Whatever happened to Sharon Maughan, by the way? We all know where her co-star wound up...
If roasting your own beans is as easy as this makes it appear, perhaps it's time for me to give that a shot, and let Fourbucks fend for themselves for a while.
Scuse me: time for a top-up.
Shades of the PVR "commercial skip" up(down)grade...
This is a discussion forum wherein owners of the RCA Rocket EBook 1100 discover that the "upgrade" to a Gemstar GEB 1150 is at least partly a "downgrade". The REB 1100 included the ability to load non-Gemstar content, using external utilities. For the GEB 1150, you must purchase all content through GemStar - if they don't offer it, then you don't read it. If you had non-GemStar content, now you can't read it on your spiffy new grayscale screen...
An additional discussion forum here, where many owners make it clear that this is a Critical Success Factor in the upgrade process.
Also, here is the Gemstar description of the upgrade. Notice how they don't mention that the device you get back won't do all the things it did when you sent it in?
And finally, just to get a full picture of the attitude of the company, try this FAQ - see the final question, where the question of having materials on your PC or Palm is addressed:
"...second, the PC and the Palm Pilot are considered "open" systems: anything read on a PC or Palm could be copied illegally."
This ignores the point that you can also copy anything read on a GemStar Ebook. You just need a scanner or photocopier.
With an approach like this, it's almost as though they would prefer not to have the inconvenience of customers.
Macrovision wants everyone to use Macrovision - and pay for the privledge. DVD producers want to buy low, sell high - and shelling out for Macrovision on a per disc basis is NOT buy low.
These days, the sheer quantity of material on a DVD relative to the price gives the package value. It doesn't need the same degree of protection as VHS tapes might have needed. Having spent all that money on content, and using a low-cost distribution system (the DVD, that is) content producers may be questioning or discovering that they don't need special protective mechanisms. Superbit DVDs only take this one step further, giving you a package that simply isn't worth trying to reproduce.
This is anathema to Macrovision. It wants "use Macrovision" to be a no-brainer decision. There is, as I understand it, a license provision for VHS recorders - in order to have the rights to use VHS technology, you had to respect Macrovision copy-prevention as well. Under such conditions, Macrovision could likely get by without either a marketing or advertising department.
The final nail in the coffin is that almost nobody dumps DVD to VHS, except maybe for the spare VHS machine in the playroom. That's all that Macrovision prevents. It does nothing to stop DVD-to-VCD or DVD-to-DivX transfers, and it doesn't even enter into the picture when large scale illegal distributors manfacture bit-for-bit perfect copies. So, why pay for technology that doesn't solve a problem.
There's been a really nice discussion going around on Ed Felten's analogy quest for the Almost General Purpose Computer. With the discussion still on-going, his favorite comparison is the Almost General Purpose Language.
Now, Almost General Purpose Computers (AGPCs) don't start off that way. In almost every case, the starting point is a general purpose computer, or at least general purpose components. Either restrictions are added, or the software is deliberately constructed so as to have limited functionality. The key point is intent - AGPCs happen by design! (They can also happen by incompetence, but I can't see any useful results down that line of thought right now.)
From this comes my main objection to most of the analogies to date - although many of them capture the idea of the AGPC, they don't elicit that gut-grabbing reaction that says this is wrong. The technical accuracy of the language comparison succeeds too well, by continuing with a rather dry, academic feel to the questions. For most of us, upon being presented with an Almost General Purpose Computer or Language, the immediate reaction is What are you hiding? or What can't I do?
My preference is to find a comparison from the legal arena that pulls up the same red-flag instincts that technologists get from the idea of the AGPC. Discussion comparing AGPCs to concepts from a 1940's novel just doesn't pull on the gut the same way.
To correct this, we need to identify the group we want to make feel this way. Felten's epiphany comes from Washington, land of lawmakers and lawyers. So we'll pull out a red-flag raising legal concept here.
The Almost-General-Purpose Computer is Prior Restraint.
For a legal definition, the closest dictionary at hand is at law.com; this is start of their definition of prior restraint:
prior restraint n. an attempt to prevent publication or broadcast of any statement, which is an unconstitutional restraint on free speech and free press (even in the guise of an anti-nuisance ordinance)
Of course, not every single action by a computer consists of publishing. But it's not the big stretch you might expect. The origins of copyright as a body of law stem from the time when technology suddenly made multiple copies easy and cheap. Computing technology has pushed "easy" and "cheap" to an extent never imagined by the originators of copyright.
Foregoing prior restraint does not remove the requirement to publish responsibly. If you're crossing the line, you will be held accountable for what you do. But it will be for what you do, not for what you might do.
That's the key element I want captured with regards to general-purpose computers. There may very well be some things you shouldn't do with a computer, things that are illegal, immoral, both, or just a really bad idea. But at the same time, there are unexpected things - things we didn't even know we could do. For all the trouble it is causing the audio recording industry, compressed audio implementations in software constitute an amazing development - one not even predicted by some of the developers of audio ocmpression. Society as a whole has a poweful new communications tool available as a reulst. You don't want to risk losing those things.
And that's why we dont't want either Prior Restraint or Almost General Purpose Computers.