The quick answer here is - it may work, but not always, and the reason is you are still pulling from the registry to get the machine date/time, which may not be correct if the registry #1 not keep current with changes, and #2 the date/time reference goes back further than the current year.  That may not be a big item for some, but for folks interested in keeping historical data like maybe physician offices where patient contact and information date/time is important, it is very important to know when something took place in relation to the date/time year of reference, and not the current year.

The original post was about the CurrentDate that's true enough, I somewhat hijacked it, because this question really emcompases so much more.  I remember expressing my misgivings about adding the routine to Core when it first was presented, citing the inaccuracies, but it went through anyway, and it's been an issue since it was release way back then.  Many won't see it, because you have to make some changes in the skin's date time formatting to notice it, but it's been an issue for a long time, and I did my best to offer the solution and to bring it to CT attention on their forum. 

At least that's the way I see it.  If you've got an example of such a javascript, I'd be willing to test it out, because if that fixes the issue for the more global solution, than I sure could use it.

To understand the issue fully, you have to understand what the registry is storing and how it is used.  Any javascript is pulling from the registry settings.  My review of those settings indicate that it is not always correct, due to the many geo-political differences around the globe, and has no historical reference.  For example, the states within AUS had to adjust their Summer Time transition date/times due to the Commonwealth Games this year, effectively extending Summer Time, not sure if all of them did, but I don't think all use Summer Time.  Now, a special update was available for those wishing to make the registry changes, but it was not offerred as an automatic update, if you are hosting AUS clients from the affected region, then you may not be showing the date/time properly or even storing it correctly.  To make matters more confusing, next year the settings go back to the previous settings.  Now, if you are keeping date/time info that is date/time sensistive for more than the current year, you need to worry about making some kind of adjustment for each year, not just the current year, which the machine setting in the registry is limited to.  The offset could change from year to year.

A good way to get an understanding of why this is important and so difficult to implement is to join the TZINFO mailing list, where the grandaddy of the TZ information is discussed.  The AUS change is just one of several that is affecting web sites this year, others are hitting too, and that mailing list is very good at alerting folks to the changes.  MS doesn't send out any notices for these kinds of issues that I know of, you have to search the KBs for mention of them.  If I'm wrong about this fact, feel free to enlighten me, I won't take offense, really.

As for the javascript examples, an example of using them in DNN is still needed, I still don't fully understand how to do that, and that's my bad, I know. 

I'm working on a solution, but it's slow going, as I've had numerous conversations with folks that provided solutions using Ruby and SmallTalk, and I've not been good at connecting the solutions to .Net.  Maybe others have that facility, and are already workinig on it.  Back to why store the tz and offset in the db, well, it's the only real way to know when a piece of data hit the db.  In using DST, there is a built-in abiguity when the transition falls back 1 hour.  Unless you store date/time in UTC, you would not be able to resolve the duplicate times for the hour that is repeated.  Not a big deal for most, but vital for others.  If you were unlucky enough to have a db in any area where Katrina hit, you probably had to move your db to another provider, and if you didn't have the ability to make adjustments on the server/machine for date/time, you would have found yourself in deep trouble to accurately retrieve information that was date/time sensitive.

It's ok to disagree, because I'm not trying to win converts, there are a lot of folks wanting a solution, not just for DNN but for other web apps as well.  DNN is my pet app, so that's what I'm working on, at a snails pace I admit.  Again, this is not really a skinning question, but a localization issue, however since it is seen in skins I just wanted folks to understand that it is a bigger issue.

I'll shut up now, and go back to what I'm being paid to do, but if you're interested we can discuss the issue in the localization forum, or you can always send me an email.  I'm a pretty easy going guy, so most always you'll get a friendly response, as I hope this is being taken as one too.

Cheers