Submitted by The extension of daylight-saving time by a month in the United States is causing enormous grief for some IT administrators running Microsoft software, as many of the software programs running on their users’ systems need to be individually patched to reflect the change. This year, daylight-saving time starts today – three weeks earlier than usual – and ends a week later than usual on Nov. 4.
MS cares for their customers like a lion cares for a gazelle. MS is a predator and you are the prey.
Over two weeks ago we patched most of our servers running Solaris, Windows 2000 and 2003 and RedHat Linux. I somehow think a lot of people put it off to the last second and now they are having problems, so it is easy to blame the vendor.
If you want to find a company that has an attitude toward its customers, try Oracle. They sent out their DST patch information on March 6!
I’ll bet that a lot of people got caught with their pants down and are blaming the vendor just like you said. However, everything I’ve heard about Exchange leads me to believe they botched the fix(es) on that big time.
“I somehow think a lot of people put it off to the last second and now they are having problems, so it is easy to blame the vendor.”
That may be true for some but, I work for a hospital system and we had been getting this together for 2-3 months. Vendors were the biggest problem. Some were trying to push different versions of Java on us, some couldn’t give you a consistent message on software readiness if their lives depended on it and some seemed not to have given it any thought whatsoever.
Believe me, the vendors can easily bear a great deal of responsibility.
We had one potential glitch with Sun’s Java patches for 1.4.2_13 that required running the tzupdater with different options after Sun verified the tzupdater failed in certain timezones. If a vendor left me hanging as a result of DST, you can bet your ass they would never see any more of my business!
This reminds me of some of the stuff we had to do when Y2K rolled around. We had a lot of software and hardware that was not Y2K compliant and we had to jump through hoops to keep it running because it was “mission critical”. How mission critical is a system you chose to ignore until you have a problem like Y2K or DST? There is a lot to be said about keeping your hardware and software up to date.
`Over two weeks ago we patched most of our servers running Solaris, Windows 2000 and 2003 and RedHat Linux. I somehow think a lot of people put it off to the last second and now they are having problems, so it is easy to blame the vendor.`
I agree with you but with qualifcations.
Our IT shop is proactive. We started out updates as soon as they were provided. This included our *nix, Linux, OS X and WinTrash servers.
McSoft does deserve a hit on this one though. ExtraChange server requites the client systems to be updated first before the EC server is patched. Typical MS planning – bass ackwards. It should be server out – but oh well – it is what it is.
For a SMB or personal network of computers this may not be an issue. In larger environments, say, like ours in academia, with well over 1,300 users and multiple lab systems this may be more problematic.
One solution is to download the patch to a WUS server and force or `deadline` its application onto the target. Fine in the `ideal` but not always obtainable.
Aside from the joke about herding cats – many in academia have different schedules, structures,politics, etc that slow the flow of the patch or upgrade. It’s no different in local business.
Many SMBs, small companies, no-for-profits, as-well-as personal networks don’t have any IT staff. These rely on the charity of others, including me as a volunteer, to help them out. I would call this the `real`.
While it is easy to sit in judgement of those who scream for help when their expensive software doesn’t perform … just remember the difference between the `real` v. the `ideal`.
While Mcoft does sell its computer virus to regular users its target audience, population and markets are businesses and large government entities, including education or academic environments.
Edited 2007-03-11 21:34
What you describe in regards to Exchange is the same with Oracle for us and a lot of other people. We chose not to update any of our databases because it would require us to update thousands of client machines. I see that as poor software design, and Microsoft hasn’t cornered the market on poor design.
And while you might not like Microsoft (and I am no big fan either) let’s keep the “WinTrash” comments to a minimum. I think in a story like this there are a lot of details that have been left out, and not everybody keeps up to date, which is where most of the problem lies.
Here is an example of real, I had four servers that needed firmware upgrades (SunFire 3800 and 4800), OS and Java patches to deal with DST issues. We piggybacked these updates in the same window as a series of Oracle patches to fix security issues. I have no sympathy for management that thinks uptime is more important than keeping systems patched and well maintained. The same people who whine when you ask for downtime are the same people who try to bury you when something goes wrong because they would not allow you to fix it. My point is how many of these “horror stories” are the result of management denying upgrades to save money, or controlling downtime so they can report “we are up” to senior management regardless of the consequences.
My experience has been with multiple Enterprise level Government Contracts, including Navy/Marine Corps Corporate Intranet (NMCI). And what I have just described is “business as usual” for these people. This is as real as it gets!
Over two weeks ago we patched most of our servers running Solaris, Windows 2000 and 2003 and RedHat Linux. I somehow think a lot of people put it off to the last second and now they are having problems, so it is easy to blame the vendor.
According to TFA, Microsoft doesn’t want to issue DST fixes for Windows 2000 unless you give them $4,000 (per system I presume). I’m slightly interested in whether your shop was able to get fixes at no extra charge or whether they pay the $4,000 per server for extended support for Win2k.
$4,000 per server. That’s pretty expensive legislation for many SMBs still chugging along with Win2k.
It’s not per server, it’s a flat fee just to get the patch. What you do with the patch is up to you after that. For most IT departments, that’s a negligible cost, aka “the cost of doing business” especially if they are running an 8 year old OS.
I say we all send our bills to the US congress…this stupid bill has a ton of folks up in arms, and the cost it’s inflicting within IT and elsewhere more than outweighs any “perceived” benefit that it offers.
The $4K cost includes all products in “extended support” – Windows 2000, Exchange 2000, Outlook 2002, Outlook 2000 and MSJVM – and can be used by a company on all of the affected machines running any of the listed products
Thanks for the clarifications guys. A flat fee is way more reasonable, but I’m sure small businesses would have liked to do something better with that $4,000. Perhaps buying a new server with the latest in Microsoft’s glorious line of server software?
I mean, this patch is a glorified registry hack. It’s easy to see why Microsoft could feel entitled to charge $4,000 for supporting an OS that was EOL-ed just a few months before this DST change hit the books, but shouldn’t they feel a obligation to their customers to resolve such a widespread and ultimately trivial issue?
I won’t be surprised to hear in a couple days that some wise guy was distributing an unofficial DST update tool that does all sorts of other nastiness. The administrator’s fault for using it? Yes. Microsoft’s fault for holding out in the name of the lifecycle policy? I think so.
I say we all send our bills to the US congress…this stupid bill has a ton of folks up in arms, and the cost it’s inflicting within IT and elsewhere more than outweighs any “perceived” benefit that it offers.
I think this is the key point here. How much energy do they really expect this DST change to save? It sure cost businesses some measurable sums in IT expenses. I’d so much rather have the “How Many Legislators Does it Take to Change a Lightbulb Act,” since at least nothing is forced upon us, and our money goes towards making a promising technology more feasible and affordable.
As long at the Sun continues to regulate the temperature within reasonable limits, I’m happy. I sit in an office with no windows for most of the day anyway, and I’m sure this is pretty common amongst the IT workers affected by this law. Now, if Congress would make a law that keeps the banks open for an additional hour, I’d be interested.
Read my last comment about the $4,000.00 price for patches.
…especially if they are running an 8 year old OS.
Dude. A lot of companies are running their back end critical systems on mainframes with code in it that is twenty five, thirty or nearly forty years old. I hate to break this to you, but for Microsoft to continue to be relevant, companies are actually going to expect them to support Windows and other software for that length of time. The only reason why they feel that they can get away with it is because the PC industry os so young. It isn’t the mid nineties any more.
Microsoft just don’t grok that.
“For most IT departments, that’s a negligible cost”
4,000$ is *not* a negligible cost for any SMB.
“4,000$ is *not* a negligible cost for any SMB.”
Then they aren’t budgeting correctly. In the end it’s only 2-3 weeks of times being off, so it comes down to which can they afford least of all: Times being off, or patching all of their legacy machines.
Well, to me that’s a glaring example of MS pressuring SMBs to upgrade for what is really a trivial upgrade.
4000$ for a SMB is expensive, and it’s not a matter of budgeting correctly or not.
I think the $4,000.00 price tag for the fix is being overhyped. I used the following page and patched our Windows 2000 Servers for free:
http://support.microsoft.com/kb/914387
The other products (such as Exchange) if you are not running the latest versions will require parting with some cash:
http://technet.microsoft.com/en-us/library/bb267339.aspx
worst part is they are just now realizing that the formula used to calculate the ammount of energy saved doesn’t account for today’s technology. Reuter’s says congress is prepared to switch it back if there is no change in energy consumption…
According to TFA, Microsoft doesn’t want to issue DST fixes for Windows 2000 unless you give them $4,000 (per system I presume).
Or smart people just read the KB article on Microsoft’s site and fix the servers themselves. It’s just a registry patch
I can’t comprehend why Microsoft must make this painful for Windows 2000 users – they’re obviously just doing it for the extra money, and to hopefully force a few more companies to upgrade as a result of this situation.
The problem is not patching the OS. Windows Updates took care of that a long time ago, as the DST patches were available in 2006 or early 2007.
The problem is all the other MS software running on top of the OS. Things like Outlook, where calendar entries are not stored in UTC, but in localtime (or something like that). Which means, once DST arrives, all your calendar entries are now an hour off. Which also means, you either suffer for the extra month this year, or you have to patch *all* your individual Windows programs.
Unlike Unix systems, where just about everything works with UTC and does time conversions using /etc/localtime / timezone settings at display time, Windows programs (especially MS apps) store dates as non-UTC dates.
A royal hassle, and then some.
That’s a rediculous statement. If that were true they’d have not issued any patch at all, or at the very last minute.
It’s a patch, no different to any other patch in process. I’d imagine the problem has more to do with administrators leaving it to the last minute, don’t want to invest the time into applying it correctly or find it difficult because it doesn’t fit into their company’s own internal patching and security processes.
Microsoft didn’t cause this problem, but hey when in doubt, blame Microsoft…
Whatever…. I’ll blame Microsoft whenever it darn-well suits me. In fact, when I pay upwards of $100+ for something, you can bet your sweet bippy that I’ll complain for half-shod quality and service in a heartbeat.
And, no *!@#$! they didn’t cause the DST problem. The series of bastardized hacked-to-death patches known in Microsoft-speak as “fixes” shows just how inept that company is at addressing problems. Even impending ones they can see that are 2 years out. Read their release notes on patching Exchange 2003 for the DST, if you want an example of just how completely incompetent their programmers and developers are. Law books are written clearer than that.
Also, any poor admin that is still dealing with an NT4 network was completely S.O.L. No patch at all for them. That’s real service for you.
But, yeah….let’s NOT blame Microsoft here. We’re supposed to drink their spoiled milk and smile as it goes down.
// Whatever…. I’ll blame Microsoft whenever it darn-well suits me. //
You’re free to do that. It doesn’t make it valid.
// The series of bastardized hacked-to-death patches known in Microsoft-speak as “fixes” shows just how inept that company is at addressing problems. //
That’s a broad stroke you’re casting across the company. Do you honestly think that Microsoft are full of inept employees? With all the money they have, do you really think they don’t employ some of the best? Do you honestly think that Microsoft’s goals are to build poor software? Maybe you should consider the reasons behind your perceived view that they build poor software. One would be naive to believe that it’s because they just employ inept people.
// Also, any poor admin that is still dealing with an NT4 network was completely S.O.L. No patch at all for them. That’s real service for you. //
Why not issue a patch for Windows 3.11 as well? Microsoft gave plenty of warning that support was to be discontinued of NT4. I went through the migration with a large international pharmaceutical company last year. These companies have some of the strictest qualification, testing and approval processes, yet we did it and on time. Yes we had to change software to newer versions or alternative products, but that doesn’t make it wrong for Microsoft the stop the support. One could argue the vendors of the software we used was inept on ensuring compatibility on newer versions of Windows, but instead lets just blame Microsoft for that too. Time to get over the NT4 support hang up. Everyone was warned well in advance.
// But, yeah….let’s NOT blame Microsoft here. We’re supposed to drink their spoiled milk and smile as it goes down. //
No you don’t have to drink it. You could choose another operating system, such as Linux, Solaris, MacOS or many other alternatives. They’re supposedly superior anyway aren’t they? A company chooses to stick with Microsoft for reasons far beyond the DST patch.
No, you can’t blame Microsoft because your idotic Admin (or perhaps company beaurocrats) are using a server OS that came out in 1996 (that’s 11 years ago, just in case you can’t count). Support has been dropped for NT4, and this has been known for a VERY long time. You can pay for extended support, but you might as well upgrade to 2000 or 2003.
But good job in showing how much of an ass you are, and most of all how much of a clue you don’t have.
No, you can’t blame Microsoft because your idotic Admin (or perhaps company beaurocrats) are using a server OS that came out in 1996 (that’s 11 years ago, just in case you can’t count).
I don’t know how to break this to you and Microsoft, but the age of NT 4 in terms of running business and mission critical systems is absolutely nothing.
I don’t know how to break this to you but Microsoft extended support for NT4 for years and if no one at the company made an effort to get support for their product (by either paying for extended support, upgrading, or changing platforms) then it is their problem.
It’s not like this all of a sudden came out of no where.
Hell, why don’t you show me even ONE *nix distro that has anywhere near length of support that NT4 had. And 3rd party support doesn’t count (you can get that with Windows too).
I don’t know how to break this to you but Microsoft extended support for NT4 for years and if no one at the company made an effort to get support for their product (by either paying for extended support, upgrading, or changing platforms) then it is their problem.
Then over the next ten years they’re going to come to realise in excurciating detail that Windows is not designed for business and mission critical systems. The code running in their mainframes is twenty five, thirty or nearly forty years old and they expect the same from their other critical systems.
Then over the next ten years they’re going to come to realise in excurciating detail that Windows is not designed for business and mission critical systems. The code running in their mainframes is twenty five, thirty or nearly forty years old and they expect the same from their other critical systems.
They may be running 30 year old Cobol programs but the OS on the mainframe has been updated many times over those years and so has the hardware.
Companies like IBM actually have a far shorter support window than you’d think for mainframe operating systems.
What people have been getting on the mainframe side is virtualization and a strong level of backwards compatability.
Here is IBM’s release and support ‘end’ dates for z/OS and OS/390.
http://www-03.ibm.com/servers/eserver/zseries/zos/support/zos_eos_d…
If someone needs a critical NT4 server and application stack for their business they should really look at running it virtually in this day and age.
To quote the user who posted with the heading Strange, I will ask the question again: Shouldn’t this be handled at the OS level?
I find it a bit strange that several applications have to be patched. Shouldn’t something like this be handled at OS level, or am I missing something here?
1. Yes, it should, but if it was, it probably would not be used.
2. Why is this not user configurable? Were people thinking, “Oh, DST is always on this day, itll never change… LETS HARD CODE IT!”
Most of these patches just change things in the registry, where TZ information is stored.
On the other hand, software like exchange which does calendaring might get screwed up when the time changes suddenly and not on a pre-defined DST change date… this is the sort of thing that’s causing all the problems. Your time changes and suddenly all your appointments are a little bit off.
Most of these patches just change things in the registry
So Microsoft must be able to find out the location of every set of TZ data that it places in the registry, for all its software, then issue one patch to change all of them in one go. Why TZ info is stored in more than one place in the registry beats me.
You’d think that because it would make more sense that way.
However, it’s likely to do with Microsoft using hidden APIs to make their products appear faster, as they’ve done for so long. This might preclude getting at the information the proper, public way and cause individual applications to be carefully and painfully patched.
Uhm, On Windows APIs can’t stay hidden for long. Enough people on the WINE and ReactOS projects are rifling through Windows code that most of the mechanisms are pretty well known.
There IS a hidden API, the Nt Native API, but not even Microsoft codes at that level in their appliations (i.e. Office, SQL, and others), because it’s undocumented, subject to change, and offers negligible performance advantages.
The reason Microsoft’s apps appear faster than their competitors is that they know Windows pretty well, or the app teams can ask the Windows team for guidance. If there’s a problem in Windows that makes an app inefficient, then Windows will fix it. But the resulting fix is then publicly available to other applications. Maybe this isn’t fair, but it’s better than the alternative. And Windows also listens to external customers.. it’s just a matter of access.
The idea that speed of querying time zone data matters to the perceived speed of an app is ludicrous, by the way.
…and we never had any support for our dynamic DST behavior.
This year, 2 or 3 weeks before DST was over (…), Microsoft kindly released patches over WUS to set DST for Brazil. Before that, we have to deal with a huge ammount of scripts and GPO’s that change the computer’s Registry.
Every year this change causes a huge the mess to Outlook Scheduling and other Database products, too.
Ugh, running system clocks on UTC is the only way to go…and then of course having a the locale offset for user display purposes.
Been burned a few too many times doing work with windows users/systems across time zones…
The client machine(s) would still need the notion of when to adjust for DST, plus there are differences between countries as to when DST actually kicks in.
So when, in January, a user sets an appointment for 16:00 hours local time on 2nd April, the computer translates that into UTC for storage using the current TZ data?
Then when the TZ data is updated in March, the appointment suddenly jumps by an hour because the locale offset changes relative to UTC? Yes, that would be good.
No. All applications should deal in terms of local time, because that’s what the user cares about. The OS stores UTC and a locale, where the locale includes offsets from UTC and the UTC ranges to which they apply. If the administrator changes or updates the system locale, the local time in the application doesn’t change, but the moment at which that local time occurs is changed.
Wall clock time is a service that should be provided by the OS and abstracted from the applications. There’s no reason for each application to worry about time zones and DST, not even enterprise calendaring apps. When I make an appointment for 4PM on April 2, that’s exactly what I mean. If the government decided tomorrow that DST will now be two hours ahead, and I update my system’s time zone data, the application doesn’t care. I still want my appointment to be at 4PM. The system will tell my application when it’s 4PM, and that’s the only part that needs to be concerned with any of this mess.
The reason for storing UTC & DST info in the application (versus only the OS) comes into play when dealing with users viewing data externally. If a traveling user is viewing their calendar from some form of a kiosk-type machine (i.e. hotel, airport, etc.), they need to know the appropriate DST offset to apply to the appt in the local time of the kiosk (since they could be anywhere in the world viewing this information). Since observance of DST/”Summer Time” isn’t done worldwide, nor is it done during the same time period (entry/exit dates), this can become an issue.
Take the following example:
A recurring meeting is organized by someone in AZ, where they do not observe DST. Attendees to this meeting live in an area where DST is observed (Central Time Zone as an example). During part of the year, the attendees local offset would be (GMT-06:00 Central Standard Time). During another part of the year, the attendees local offset would be (GMT-05:00 Central Daylight Time).
During the time of year where DST is observed, the recurring meeting would “spring forward” on the attendees calendar. This happens because the organizer does not observe DST, and consequently, the UTC time of the meeting is unchanged, but the attendees local time for the meeting has changed.
In the reverse scenario, if the organizer observes DST, but an attendee does not, then the meeting would “fall back” on the attendee calendar since the UTC time of the meeting is now occurring one hour earlier.
In the above example, if both the organizer and attendees both observe DST during the same time of year, then the appts would stay at the same time slot for both the organizer and the attendees.
The complexities of who is the organizer, what DST rules they follow (if any), and who the attendees are, and what DST rules they follow (if any), make it imperative to store both the UTC and DST information within the application, especially if the user is viewing this information on something like a kiosk.
Edited 2007-03-12 05:00
Oh I agree with you, hence the implicit sarcasm in my last post.
The problem with your ‘All Applications should deal…‘, is that this shouldn’t apply in every instane. User defined times (especially appointments etc.) should be stored in UTC + locale, or local time. However things like Log entries, file stamps (Including the Microsoft Meta-Document creation time) and other computer-specified time events, should be stored as absolute values (Idealy UNIXTIME style) and then translated on demand. That way, you can rely on the computer being technically correct all of the time, for things that matter.
“Ugh, running system clocks on UTC is the only way to go”
Sure, but it is not a solution to this problem.
…on my mac.
No problems on my Windows XP machine either.
IMO, we should just get rid of this daylight savings crap. Thats the real culprit of the problems.
No problem on XP, Server 2003, or Vista.
Updaing all jvm’s was my only pain, not too bad. Seems like a serious design oversight there. Shows to go you can’t take anything for granted.
For any Novell GroupWise admins out there, if your GWIA is delivering mail inbound or outbound oof by an hour and you have upgraded to whatever SP or IR that should have the DST fix, restart your agents on that box and that should sort it out.
Edited 2007-03-12 01:00
At work the pain it gives me just writing about the Windows NT Servers (Production work) running on them. The pain continues on to Windows Server 2000 & 2003 what a mess. I cannot comprehend why they don’t migrate of this old hardware/software other than stuborn users will not stop using this legacy stuff.
I have to say with Red Hat RHEL3/4 there was a patch it was pushed down by a Software sever and all that was required was ‘node cycling’ not a reboot just the services cycled. On the Windows side it required reboots and that is where the fun begins. Will Windows NT Server ever go away it is really like a bad dream or virus and the file system is a total nightmare in any Windows OS!
I saw a package called tzdata being pushed as an update weeks ago when updating Etch here (my personal machine, mind you, and one that won’t be affected by this DST mess) and I had no idea what was that for. Now I see why! Now, THAT is customer service…
Considering this was handled by apple in March of 06 with the update of 10.4.6 I would call that customer service
“Considering this was handled by apple in March of 06 with the update of 10.4.6 I would call that customer service”
Apple doesn’t have a gazillion edge cases they have to account for, nor many large complex multi-timezone networks. They also don’t have the political pressures (aka fortune 100 companies breathing down your neck) that MS does either. They also have a very forgiving user base…when they do screw up, they are given quite a bit of leniency.
I don’t think it would be too much of a stretch to venture that virtually no MS home users have had any issues with this patch. It’s large, complex networks where issues are arising.
April of 2006 is not correct…
The Daylight Saving Time Update(s) for MacOS X 10.3.x through 10.4.x were published by Apple on 02/15/2007 (see URLs below).
There is no update for users running MacOS X 10.2.x or earlier…
MacOS X (Tiger) – 10.3.x – http://www.apple.com/downloads/macosx/apple/macosx_updates/daylight…
MacOS X (Panther) – 10.4.x – http://www.apple.com/downloads/macosx/apple/macosx_updates/daylight…
anonUmus,
You’re right! April of 2006 *is* not correct:
It was February 14, 2006, Mac OS X 10.4.5 Update:
http://www.apple.com/support/downloads/macosxupdate1045.html
http://docs.info.apple.com/article.html?artnum=303179
-time zone and daylight savings for 2006 and 2007
Those most recent ones was “Dad” (you can call him “Steve”), just makin’ sure the kids we’re all tucked in with their Java and last minute look in to see if we’re all doing OK and NOT FIGHTING, you know, like kids do.
Maddening. Isn’t it?
From our friends at the University of New Hampshire:
Download and install the CIS DST Fix package for Mac OS X 10.3.9 and below
(Update for users running Mac OS X 10.2.x or earlier)
http://pss-mac01.unh.edu/howto/DST_fix.html
Overall Advice:
http://cis.unh.edu/index.cfm?id=829B4055-D672-CF1C-DB8FCB9351378084
P.S.
The Window’s patches worked like a charm.
Daylight Savings, or Summer Time, depending on where you live in the world, is not just a “US phenomonon”.
The February 2007 patches from Apple include all of the worldwide time zone changes known as of Jan. 8th, 2007. Emphasis on the “worldwide time zone changes”…
http://docs.info.apple.com/article.html?artnum=305056
Some additional regions that recently adopted time zone and DST changes are available in the February, 2007 Daylight Saving Time Update. This includes rule changes (as of January, 2007) for Australia, Brazil, the provinces of Alberta and British Columbia, Canada and several other regions.
The Java update you refer to above was, in fact, a separate update available on Feb. 15th, 2007 as well – it was in no way tied to the DST update Apple posted.
If your view of the world only includes the four main timezones in the US, then yes, you would be correct in saying that Apple had this taken care of when they released MacOS X 10.4.5.
For the rest of us who live in a world more expansive than the four main US time zones impacted by DST, the Feb. 15th, 2007 update is the one that really matters.
The “Administrators” that I have delt with are not really half as trained as they think they are and really don’t plan ahead at all. When they drop the ball it is much easier to pass the buck to the software vendor than to get in front of anything. I sell a software package that does a lot, but is limited in some ways…the administrators that I sell it to just think that it should do everything under the sun without even trying the software…they just assume all the work has been done. They do this with everything, and I am consistantly amazed at the lack of understanding and training that most of them have with computers. Many don’t even know basic things about how a computer works…no wonder the DST is such a big deal.
Dano.
Very true. Unfortunately, IT is seen as a money losing investment in the US now, so it’s either ignored until there’s a disaster (at which point there are calls to vendors or ISPs demanding apps oe internal networks are troubleshot, gratis, over the phone), offshored, or populated by the cheapest person who can do the job semi-competently. Training is the exception, not the rule these days, so the on-the-ball system admin follows the same schema.
M3 Sweatt?
Yo! It’s M3 from the DMZ, Yo man on DST!
Say Bro, whassup with NTP? Got no sh*t on my BSD.
So all you s*ckers on MSFT, go f*** yoself on MTV
Edited 2007-03-12 04:56
No DST here.
Too close to the equator.
My company of ~1000 (12 offices worldwide, Win2k3 domain with Exchange 2000/2003, around 1500 clients total) was patched over the weekend. The infrastructure guys sit on the same floor as me and are saying they had zero issues.
The 80/20 rule is probably in effect here…20% of the companies out there making 80% of the commotion. What needs to be understood is that any time new code is introduced into a non-trivial infrastructure setting, problems can (and will) arise.
We applied a patch at our work, but it appears you need to patch the patch to get some computers updated properly…BRILLIANT!
I’m on EST but I turn off the daylight savings time feature and use the Exchange Server as a time server so the clients get updated from that pc.
Heck, even under OS/2 it’s easy. I changed my one line in my CONFIG.SYS from
SET TZ=EST5EDT
to
SET TZ=EST5EDT,4,1,0,7200,10,-1,0,7200,3600
and everything was happy the next time NISTTIME ran from CRON/2. 🙂
I can’t say we have had any show stoppers at my work.
Approx 151,000 systems have been updated and beyond a few machine specific calendaring issues everything is running as it should.
They should be ticked at the Legislature that is meddling with their time to begin with.
It’s the idjit politicians that need to strung up for this mess.
anonUmus writes:
“Daylight Savings, or Summer Time, depending on where you live in the world, is not just a “US phenomonon”.”
Title of article and description:
(at top of page)
Microsoft Customers Irate Over Daylight-Saving Time Woes
The extension of daylight-saving time by a month in the United States is causing enormous grief for some IT administrators running Microsoft software …
“If your view of the world only includes the four main timezones in the US, then yes, you would be correct in saying that Apple had this taken care of when they released MacOS X 10.4.5.”
That’s all I wanted to state.
I didn’t realize the latest patches were for different world zones, … learn something new every day.
Java for Mac OS X 10.4 Release 5
February 15, 2007
http://www.apple.com/downloads/macosx/apple/macosx_updates/javaform…
-Java for Mac OS X 10.4, Release 5 adds support for the latest Daylight Saving Time (DST) and time zone information as of January 8, 2007
Win2k DST Unofficial Patch
Unofficial Windows 2000 Daylight Saving Time Patch
http://www.intelliadmin.com/blog/2007/01/unofficial-windows-2000-da…