This is an old issue, but I just completed a review of the information which is stored in my Windows XP Pro SP2 registry. As you all know we can set our machines by clicking on the Date / Time Clock in the task bar, which brings up the Date and Time Properties
application. Accessing the Time Zone tab brings up a nice dropdown list and map that you can use to set your time zone for your machine.
Now, I often wondered where that information was stored, and how to actually make use of it for my own applications. After some web mining, I found various snippets of information, but none really sutied my purpose. However, I did manage to piece together
some code that accesses these registry keys and create a file that I converted to a spreadsheet for review purposes. Bear with me, now.
In earlier posts I forwarded the suggestion that the simplest approach to incorporate DST into DNN was to manually set fields that stored the Start and End dates , and the Bias (difference). Several discussions followed about the existence of the MS registry
information, and libraries that probably could be used for a more efficient solution. Now, thinking about it, this sounded promising, but no one actually contributed to the effort, and don't know if anyone even tried. No matter, though.
I subsequently found some information that shed a bit of light on how the DST settings were incorporated for use by the OS to set up machine date time. Good stuff, I thought, so why not mimic it? I did and was able to set up a nice way to store the DST
bias, start and end dates in a nifty fashion. Of course, this means some core changes, but it was worth it for me. Now, due to some heavy workload with my day gig, I had to drop working on this approach. As time moved on, I recently was asked about the
subject again, and armed with some new knowledge, actually wrote the bit of code to display the registry information for all 75 timezones in my OS registry. Cool, huh?
Well, after going through this a bit, thought it would be nice to check the accuracy of the information. This morning I completed my first round of review. I can now report that the registry information is only 76% accurate. Why? Well, the main reason
is the constantly shifting use and description of DST rules, which are not universal, and due to the inaccurate grouping of cities in similar time zones, which may not share operational standards for DST usage. So much ado about nothing. The registry only
seems to be accurate for the more developed locales, which I understand, and don't even know where to begin with Calendar differences.
Long story short, I really believe that the best approach to providing DST for use with DNN is to allow Admins to manually set it up. I do not believe we could ever completely trust any type of automatically adjusted framework that is dependent on the registry
given the inaccuracies I found.
Just wanted to share this information as I thought it worth mentioning. Anyway, if you are interested in learning about what I did and what I found, just add to the thread, leaving some contact info, or leave me a forums private message. I'd be more than
happy to share the info.
Also, if others have a view on the subject or an approach that already works in our global setting, I'd love to hear about it, as well.
At any rate, sorry for the intrusion with your regularly scheduled posts, and may you all enjoy the fruits of our community labor.
iwonder
Star
8502 Points
1699 Posts
On Time Zones and Daylight Saving Time (Summer Time)..
Dec 22, 2005 06:20 PM|LINK
This is an old issue, but I just completed a review of the information which is stored in my Windows XP Pro SP2 registry. As you all know we can set our machines by clicking on the Date / Time Clock in the task bar, which brings up the Date and Time Properties application. Accessing the Time Zone tab brings up a nice dropdown list and map that you can use to set your time zone for your machine.
Now, I often wondered where that information was stored, and how to actually make use of it for my own applications. After some web mining, I found various snippets of information, but none really sutied my purpose. However, I did manage to piece together some code that accesses these registry keys and create a file that I converted to a spreadsheet for review purposes. Bear with me, now.
In earlier posts I forwarded the suggestion that the simplest approach to incorporate DST into DNN was to manually set fields that stored the Start and End dates , and the Bias (difference). Several discussions followed about the existence of the MS registry information, and libraries that probably could be used for a more efficient solution. Now, thinking about it, this sounded promising, but no one actually contributed to the effort, and don't know if anyone even tried. No matter, though.
I subsequently found some information that shed a bit of light on how the DST settings were incorporated for use by the OS to set up machine date time. Good stuff, I thought, so why not mimic it? I did and was able to set up a nice way to store the DST bias, start and end dates in a nifty fashion. Of course, this means some core changes, but it was worth it for me. Now, due to some heavy workload with my day gig, I had to drop working on this approach. As time moved on, I recently was asked about the subject again, and armed with some new knowledge, actually wrote the bit of code to display the registry information for all 75 timezones in my OS registry. Cool, huh?
Well, after going through this a bit, thought it would be nice to check the accuracy of the information. This morning I completed my first round of review. I can now report that the registry information is only 76% accurate. Why? Well, the main reason is the constantly shifting use and description of DST rules, which are not universal, and due to the inaccurate grouping of cities in similar time zones, which may not share operational standards for DST usage. So much ado about nothing. The registry only seems to be accurate for the more developed locales, which I understand, and don't even know where to begin with Calendar differences.
Long story short, I really believe that the best approach to providing DST for use with DNN is to allow Admins to manually set it up. I do not believe we could ever completely trust any type of automatically adjusted framework that is dependent on the registry given the inaccuracies I found.
Just wanted to share this information as I thought it worth mentioning. Anyway, if you are interested in learning about what I did and what I found, just add to the thread, leaving some contact info, or leave me a forums private message. I'd be more than happy to share the info.
Also, if others have a view on the subject or an approach that already works in our global setting, I'd love to hear about it, as well.
At any rate, sorry for the intrusion with your regularly scheduled posts, and may you all enjoy the fruits of our community labor.
Peace is Possible [;)]
Phil 'iwonder' Guerra
Mission, KS - USA
Mission, KS - USA