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).
leupold
Contributor
6015 Points
1197 Posts
Re: On Time Zones and Daylight Saving Time (Summer Time)..
Jan 17, 2006 11:44 PM|LINK
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
gamma concept mbH
DeutschNetNuke = DotNetNuke in German
DNN Project UserDefinedTable