December 19, 2006 at 5:32 pm
DST Ready
I know SQL Server will handle the upcoming DST change (3 weeks sooner in 2007 to start 3/11) without requiring any patches; however, there is an OS patch available from Microsoft for Windows Server 2003 and Windows XP (none for Windows 2000). There is also a patch needed for the Java kernel (all flavors) and I think for most other database platforms. There are also updates needed from many 3rd party control vendors, as well as many software applications. People should not make the assumption that if they patch the OS everything will work fine.
Although many Windows programs may very well rely on the OS for time (like SQL Server does), many do not, especially Java based applications or really any application that is written for multiple OS platforms (i.e., Windows and UNIX).
The import of this change can be very important if you are in a business that relies on the exact time in any way, and especially if you have multiple servers in multiple time-zones that communicate with each other. Being in a business that deals with monetary transactions we have been working on making sure our applications will accurately recognize the time change on 3/11/2007 for a number of months now. We will be going right down to the wire on this "project". The level of work related is not on a par with the Y2K scare, but the breadth of work certainly is...every program needs to be evaluated.
There may be some wrinkles as people work through this. For example, we developed a proprietary replication engine back in 1994 that we are still using today, and it was developed using a C++ 3rd party library that handled among other things time-stamping of all records in the database. As a side note, we have not switched to SQL Server Replication because our current engine works, is fast, and is still the only replication engine I am aware of that compresses all data packets for faster replication over low bandwidth connections, which was important for us given the rural nature of many of our clients. Anyway, when we built this program in 1994 we paid around $2,000 for the library distribution license, but when we looked at upgrading to their newest version that contains this DST fix it was going to cost us $165,000 for the same license. Needless to say, with a budget allocation of $0, we ended up modifying our code to work while still using the old library versions. Development time and testing time turned out to be less than two weeks, which put this project in the "lucky" column.
How many more problems like this are there? In many ways we are fortunate in that the core applications we have developed are exclusively for the Windows and SQL Server platforms and rely on those to handle the time functions we need, and our replication engine was the only one of the applications we have developed that needed work, but we are still working through our list of 3rd party applications.
Note: Microsoft SharePoint and Exchange did not rely on the OS, so they have patches that will need to be applied. We are hopeful that we have everything covered by 3/11. This is certainly a challenge in that we did not have any money or resources allocated for this when we started the year.
Word to the wise...check your DST readiness now.
John
Note from Steve Jones: John sent me this editorial and asked his last name be withheld. I thought I wouldn't add too much to his well thought out notes, so I ran them as is.
December 20, 2006 at 6:27 am
Thanks for the heads-up. I was not aware that Exchange and Sharepoint managed time separately from the OS - until now. Since we use Exchange 2000 and do not have an extended support agreement, I will have to scrounge the hotfix from someone. Hopefully, MS will make it widely available.
December 20, 2006 at 6:53 am
This whole thing is a bundle of troubles, especially for multi-nationals dealing with differing rules.
Personally I think a central timekeeping should be UTC/GMT with local translation done on the fly at the client. Actually since UTC is subject to leap seconds, perhaps the best choice would be UTC-1.
...
-- FORTRAN manual for Xerox Computers --
December 20, 2006 at 8:15 am
You only need the Exchange update if you use CDO functions of Exchange like web access - Outlook uses the OS for time.
Joshua Perry
http://www.greenarrow.net
December 20, 2006 at 9:13 am
Steve,
Not everyone knows DTS stands for Daylight Savings Time. Please include what your shortcuts stand for, DTS in my neck of the woods could mean many things, especially at Boeing - they are the king of acronyms.
John
December 20, 2006 at 9:37 am
Good thought, Jay, but go further. Local times are 19th century thinking. It's just a number on a clock. I can set my alarm for 18:00 or 06:00 just the same. I have been saying for years that AM and PM are for those people that can't count beyond twelve.
ATBCharles Kincaid
December 20, 2006 at 9:55 am
Time sensitivity is really important in a number of areas. It is of tantamount importance in the healthcare industry, even more important than in the financial realm. In finance people and businesses can lose money, in healthcare people can actually lose their life !
Our environment is entirely 3rd party vendor applications. Windows, Linux and AS400. Our applications range from 2 tier and 3 tier applications, mainframe and even a few standalone applications. For us this time change thing is really a non-event. This is something that we are currently doing already due to the plethora of vendors and architectures that we support. The only thing that will change for us is the dates of these semi-annual fire drills occur.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 20, 2006 at 10:01 am
Good article, John Annon.
I have an idea for Windows 2000. Go to http://www.thinkman.com and get the free software. Set it up to allow for 24 hours of correction.
Our apps track things to the second. We do lots of production recording using fixed location bar code scanners. A box without a good bar code gets kicked off the line and the good bar code gets recorded into both inventory and the production log. Our users are used to those two hours per year, one with the double recording and the one with nil recording.
We have an app using wireless devices out in the field for sales order and service order processing. We had to patch it to deal with time zone changes.
ATBCharles Kincaid
December 20, 2006 at 11:26 am
In going to thinkman.com, my iPrism web filter blocked it and provided the following message:
"The restricted viewing of this site (http://www.thinkman.com/), was due to the rating of its content (spyware/adware). "
This might be a improper classification, maybe not. But I tend to rely on the filter and seldom have issue with it. Can anybody verify or deny this?
As far as DST goes, just make it go away. DST has little effect in the summer here in the upper latitudes of the planet. We need it right now as it is still dark outside and will be for another 1/2 hour or so. I shouldn't complain, further North it won't get light for another month or so.
Oh 12/21, I can't wait for you to return!
Good article otherwise.
December 20, 2006 at 11:34 am
Bob: Sorry that you are having filter problems. The software is good stuff. Don't know why it would have got blocked. Anti-virus an Windows Defender don't complain. Ah well. It's not my site or software. I'm sure that there are other free-ware tools that do the same thing.
ATBCharles Kincaid
December 20, 2006 at 11:38 am
I was able to get in with no problems - we are using WebSense as an enterprise internet tracking and blocking.
What latitude and time zone are you at ?
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 20, 2006 at 12:12 pm
Latitude: 61° 13' North
Longitude: 149° 52' West
UTC/GMT -9 hours
Sunrise today is at 10:14 AM in direction 143° Southeast by south
Sunset tonight is at 3:41 PM in direction 217° Southwest by south
Duration of day: 5 hours, 27 minutes (19 seconds shorter than yesterday)
Sun in south at 12:57 PM at altitude 5° above horizon
I guess I would be in support of universal planet time. Man's tinkering is getting things out of whack. Years ago, we used to have 4 time zones, now due to economics, we only have 3 but the Sun didn't move to match them!
December 20, 2006 at 12:50 pm
... and I thought I was a mushroom in the winter (lack of sunlight) ...
Valparaiso, IN (US): 41n28, 87w04
About a 10 minute drive from the southern edge of Lake Michigan.
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
December 20, 2006 at 4:43 pm
Don't mind Bob. He's got brain freeze from standing outside the office door too long looking for the sun
December 20, 2006 at 5:09 pm
Three cheers for Arizona and Hawaii: We don't need no steenking DST.
(But why is it colder here in Phoenix today than in New York? One of nature's cruel jokes?)
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply