DST

Three letters that I am positively sick of hearing.

I remember reading about this first on Peter K’s blog and – shame on me – it registered but wasn’t top of my to do list. Well, it is now. Several other bloggers including Chris Foot have talked about the changes in the date that Daylight Savings Time takes effect in North America.

It’s not as though people didn’t know it was coming (although if you’re not based in North America or don’t have users across time zones it could be insignificant), but I think people have underestimated the impact. By that I don’t mean the true impact. A lot of sites will be unaffected if they never use timezones and time gap calculations and I can imagine a lot of systems will never be patched properly, no-one will notice and the problem will be solved by a future upgrade. I mean the impact on companies of all the patching they have to do to be sure.

The extent of the patching? Try operating system, RDBMS, application servers, clients (they have timezone files, too), JVM, system management tools, ERP applications … the list goes on.

For example, Metalink Note 402316.1 talks about the cascading effect for Enterprises with large numbers of Oracle servers and clients.

“This means that if you apply new time zone files to database A, then
all clients that connect to database A (and use the affected
timestamps) will need the same patch as well. Subsequently this also
means that if one of these clients also connects to database B, then
database B will need the same patch as well, which means that all
clients that connect to database B need the patch, etc. etc.”

Then you have to determine if your application code will be affected, which is perhaps straightforward for stored PL/SQL, but what about the rest?

Am I the only one who finds the Metalink documentation a shambolic nightmare? Everywhere I look there is a document I’ve not seen before with a new twist on the problem. It’s improved recently as Oracle have introduced a dedicated category in the Metalink knowledge browser, run webcasts and tried to point people towards a master document which looks like note 397281 to me. Still, I’m often asked questions that I realise I’m not sure of the answers to and so I end up rooting through the documentation (again) for a definitive answer. I get even more worried when I see new or updated documents at this late stage in the process 🙁

I suppose I’ve been lucky so far in that I haven’t come across any data that needs to be backed up and restored, so life could be worse.

5 comments

  1. The problem is a little bit complicated than for Canada due to the fact that certain provinces (states) decided to go with the change much later after it was announced.

    Oracle Support recently published an update (v4) for Canadians in that the previous patches didn’t include the later provinces like BC so that even if you had done your patching earlier and you are in British Columbia, you will still need to apply the latest.

    My guess was that Oracle didn’t clue in and probably some customer did applied the v3 patches and actually tested them to find that it didn’t take for Pacific Standard Time.

    As of last Friday, patches for JVM for certain versions are still pending. Time is a-ticking…another thing to keep in mind too is that some Oracle clients might need to be patched and Oracle Support is not helping with too many of these Metalink articles referring to each other.

    Even the mainstream media have caught on and are comparing it to another “Y2K” issue.

      1. I am with you on this one Doug. The FAQ on metalink is update, hmm…every other day.
        *
        Wow! I am ready to pull a couple hairs out. In Windows land, looks like you have to install a patchset to get the fix. Starting with Patch9, which they are up to patch10 or patch 13..not sure Goodness!! As for the JVM..like Peter indicated, tick,tick

Leave a comment

Your email address will not be published. Required fields are marked *