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

Ok, I'm just going to offer this information, even though there just doesn't seem to be a whole lot of interest, which is surprising to me, given the global acceptance of .Net, not just DNN.  Of course, I could be misreading the situation, and most are satisfied with the status quo. Maybe it's the poster, and not the topic (always a possibility). In any event, here's what I've been thinking about...

Towards A Solution

Key Goals

1.       Provide an easily localizable list of time zone information.

2.       Include rules that auto-adjust date time information using reference rules for the the following: unauthenticated user (portal preference), authenticated user (user preference). 

3.       Include ability to store/retrieve historical time zone references

4.       Support the minimum 75 time zones already available in the Windows registry, but do not limit the solution to only 75 time zones.

5.       Assimilate TZInfo where appropriate.  It may not be practical to implement all known information from the TZInfo database. Might need to offer a method for Hosts or Admins to specify which Time Zones are supported.

6.       Avoid complicating storage methods, enumerate with simple encoding, rather than structures that are used for internal storage.

7.       Include longitude and latitude of Time Zone description, which could be very useful for future development.

8.       Publish limitations on usage.  For example, a practical solution for DNN may not offer auto-conversion of data prior to 2003 and may not display accurate date time information for years beyond the current year + 6 months.  Time Zone information varies according to no set standard reference, and therefore cannot accurately assume that rules engaged beyond these limitations will be correct. Discretionary use is advised.

Why Can’t The Windows Registry Timezones be used?

First, and foremost the 75 windows registry timezones only are setup to support current year.  Meaning that there is no historical reference.  In fact, when a given locale changes their time zone daylight saving (summer time) rules, these rules need to be manually ‘fixed’ in the registry.  These types of corrections are not distributed by Microsoft as updates to anyone.  The corrections appear in KB articles, but the corrections could easily be missed by folks that are not in the locale affected.   As each year starts, new rules are in place, which may not calculate the correct date time adjustments for any past years.  Actually, any date time adjustment based on the registry alone results in a date time factored with the current years’ rules.  Not exactly the result time sensitive sites would require.

 

Secondly, the windows registry is not totally accurate.  Independent tests show it to be around 75-80% accurate at any point in time.  Also, the time zones do not represent every time zone on the globe, just the more commonly used zones are included.  The UNIX / Linux TZInfo database includes many more time zone descriptions, but there is a question of just how many require support.  Obviously, MS made the determination that only 75 of the more than 108 zones in the TZInfo database really require support.  It’s a question of judgement.

 

Lastly, web applications are not really meant to have access to the windows registry.  It’s really a question of security, but I can’t imagine any host provider wanting to allow a web application to manipulate the registry.  In fact, I’m not sure if the Code Access Security model will even allow the type of registry read and write permission required to effectively use and maintain a registry timezone information.

 

Why not use the TZInfo database for the solution?

That’s not an easy solution to manage either.  First of all, there is no single authorative time zone source.  Yes, the TZInfo database has the distinction of being the most inclusive database of time zone information, however, it is not the sole authority.  The TZInfo database was built over the years with contributions from various sources, and there is no assurance that the information is 100% correct.

 

For historical references, the Olson database, as it is also known,  is unmatched, but in general any daylight saving time rules before 1970 are suspect.  Even in the USA, daylight saving time practices varied from locale to locale, and sometimes cities less than 30 miles from each other had different rules for using or not using DST.

 

Now, with all of that history, it seems more important to build on what the TZInfo database has collected, and integrate a more valid approach for future use.  While working to incorporate the full TZInfo database into a .Net solution might be desireable, it really may not be practical or worthwhile, given the lack of accuracy inherent in the data, conversion issues aside.

 

Finally, any .Net solution has a requirement to be easily localizable, something which I’m not sure is possible with the TZInfo database. 

 

Why not use Michael Brumm’s SimpleTimeZone Class?

 

While the SimpleTimeZone class fills a certain void in the .Net classes to support time zones.  Again, the class would seemingly have issues with operating in less than full trust mode when used in conjunction with reading the windows registry.  As mentioned above, the registry only provides information for the current year.  So, the SimpleTimeZone class is a useful model for building a solution, but is not the lone answer either, unless a database of time zone information other than the registry is used.

 

Why not build a .Net time zone database?

 

Precisely!  It seems to be the only answer that leads to including all of the requirements of a .Net solution.  However, building a time zone database is not an easy task either.  First, question is how many years back does the database support?  How many time zones does the database need to include?  What format should the database be in?

 

These are just some of the issues to overcome.  I’m sure others are going to pop up as the process gets rolling.  In the end, it’s just a question of time, isn’t it?

 Now, if you are wondering what the TZInfo database or Michael Brumm's SimpleTimeZone class are about, just do an internet search.  Maybe, you didn't know that most .Net web apps are not really showing you the date time you think they were.  Should you care?  Only if you care about a certain degree of precision in presenting date time information.

Now back to my reqularly scheduled support activities...

Cheers

IWonder,

I am glad to hear, that DNN CT is caring about this subject. As DNN is used all over the world, exact time display becomes more and more necessary - and will even more in the future, when content localization will be available.

Regarding your proposal I would like to suggest a step by step solution. 1, 2 and 8 are the most important from my point of view - even Win95/98 (not sure about Win2K at the moment) presented the user a dialog, to check adjustments when they were done automatically.

4 & 5 seem to be of value for large installations, most users and hosts will not be concerned.

6 is an internal question about the implementation - but, of cause, simple solutions are generally preferable.

I cannot see the advantage of 7, and I do not see, how to archieve this. you cannot store a region around a time zone nor a time zone for each coordinate.

IMHO 3 is very dependent on usage. It would be preferable to be implemented, but maybe can avoided, as all datetime values, that needs to be exact, should be stored internally as UTC. And all events, that have passed for a couple of months usually don't need to be that exact /if the time shift is consistent and e.g. the time zone displayed as well).

So for most values you only need to display the current and near future DST correction and - in the first step, I would accept to have an adjustment option in portal settings and user profile and a function, that is called by all time consuming or displaying modules, so this function can be enhanced behind the scenes, so future versions and all modules will benefit from enhancements automatically (if they use it).

Just my 2 cents.

Sebastian 

Sebastian,

Thanks for engaging in this dialogue.  It's really important to me, anyway, that whatever course of action is taken be part of an international effort.  Personally, I don't really 'need' a solution, but my interest tends to favor a global solution.  With my involvement in DNN, I've gained many friends from around the globe, and the accurate localized display of date time information is a common complaint.

The goals I enumerated are not meant to be official DNN CT position.  I've actually retired from the CT for personal reasons, not for lack of interest.  Just a lot on my plate at my day job prevents me from fullfilling my DNN CT functions.

Now, in reply, I certainly agree that stepwise implementation is the preferred route.  However, before we can actually take any steps, we must be clear about the end result desired.  For me, all of the points are goals mentioned are important to include in the overall solution.  However, the solution I envision allows for the level of granularity used to be flexible.  Also, the goals were not in order of preference or importance, just a numbered list to engage in discussion with a way to match comments to them.

I agree, 1, 2 and 8 are maybe the top priority.  Points 4 & 5 may be of concern to only larger concerns, but the idea is to provide a good base to begin.  My exploration of the windows registry and investigation of many time zone related sites, and documents showed me that practical considerations should include at least the time zones enumerated in the base Windows operating system.  It's not that difficult to allow for all of them, and certainly would follow an obvious marketing decision by MS, which can't be all bad.  As for point 5, including the additional timezones offerred by the tzinfo database, again I can forsee the effort to be worthwhile.  Now, the key to me is to allow a method to limit actual display and use on any portal a choice of the admin.  In that respect, I find many usage cases where only the existing number of timezones used with DNN more than adequate.  However, global businesses benefit from the improved granularity.

Point 6, you've rightly expressed my intention.  I just mention it, as in working with the timezone class used with exploring the registry, the tzi portion is difficult to understand for most non-programmers, and a simplification would no doubt be appreciated.  Though internally, the use of structures to handle tzi-like formats offer performance improvements.  The keys to keep in mind are that the solution needs to be easily localized, and easy to administrate.

Point 7 is very do-able as part of extending the granularity of the solution.  In our existing implementation, we store the actual UTC offset.  While this allowed some simplification, it has also limited the approach to a better solution.  I believe, we are better served by storing a timezone identifier that is a key to lookup table, which could include any amount of granularity.  Now, the actual timezone database doesn't actually have to be a strict database format, but I used the term to signify that the information is a data store, whether the actual format is xml or sql or other format.  In fact, the Windows registry includes a MapId that keys a display of a simple map whenever you change timezones on a local computer.  It's not really lat / lon driven, but my point is that a solution could provide the information.  It doesn't have to represent every known locale, but only the central coordinates of the time zone in question.  Again, it really just depends on the amount of flexibility allowed in the design.

Point 3 regarding historical storage and retrieval is something that many might not find immediately valuable.  However, as more global business, and academic sites become users of .Net concentric applications, a solution needs to provide this type of flexibility.  MS has stated in some posts I've read that they've not had many requests for it, but speaking to academic and other parties, there is more than enough usage cases to allow for the solution to include the year of any date time adjustment to be included.  Again, it's more of a design issue, allowing Admins to choose the level to engage is a better approach than limiting it IMHO.  Windows limits to the current year, while other operating system allow a more flexible approach.  One thing I don't like is being told that a calendar system allows for dates from year 0001 to 9999, and not being told that date time adjustments are actually only made with the current year's description of the adjustments.  Maybe hair spliting, but a better approach is possible, and not that much more difficult.

All in all, in order to achieve the goals, I'll be looking forward to hearing in more opinions.  I'm interested in bringing a better solution to the .Net framework and not just DNN.   There are many issues to overcome, including decisions of how to internally store date time information, which for most at this point is simply using the server machine setting, rather than UTC.  Again, it's up to the community what is important, but that's why I've posted this information - to engage others.

Thanks for listening...

Cheers

 

iwonder, I'm very interested in your thoughts on this.  While I'm not working on DNN integration, I am in the process of developing a large web site/database solution for my company.  I'm not sure how big it will grow or how many features I will add, but I'm very interested in reporting dates/times accurately.  It's truly a shame that there is no built-in solution for this in the .NET framework.

How far along have you come on your implementation?  I read in another forum that you will make your solution open source.  If I can contribute anything, please let me know.  I'd love to be a part!  If you'd like to contact me directly, please e-mail me at gsmith_lsu (at) yahoo (dot) com.

Greg

Greg,

Well, got caught up in some day-gig stuff, so I missed my original target date.  Hopefully, I'll catch up and have something ready to show by the first week of April.

There's a lot of things still to work out, including example applications and such.  I'll drop you a note later to touch base.

Thanks for the interest and offer to help.