 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / CLR / October 2003TimeZone and DateTime - what were they thinking?
TimeZone - the only instance you can get is one representing the local time zone DateTime - cannot represent a time before 00:00:00 1 Jan 1 CE What were they thinking? This is a serious question - can anyone come up with a good reason for these incredible design restrictions? Michael Brumm http://michaelbrumm.com has produced a fix for the first problem with his SimpleTimeZone class - good on you, Michael! Any thoughts on how to deal with the second problem? Cheers - rick cameron Hi Rick! Long time no see.... For #1, you already know the answer -- it is based on the OS support, which has this limitation. I do like Michael's SimpleTimeZone, but there are still issues that are kind of inherent in some of the fundamental instabilities of time zones as a whole. The most important note is that Michael himself recommends always using UTC and then converting to local time for display ONLY -- which is what MS had advocated since the beginning, what they use in AD and email, and what actually causes the SimpleTimeZone to be able (in most cases) from a requirement to an optional cool feature. For #2, its hard to understand the meaning of Gregorian calendar dates before the calendar existed. Maybe you could explain the actual scenario and how you would account for the lack of the actual calendar for the dates you want to represent?  SignatureMichKa [MS] This posting is provided "AS IS" with no warranties, and confers no rights. > TimeZone - the only instance you can get is one representing the local time > zone [quoted text clipped - 11 lines] > > - rick cameron Hi again, Michael #1 - It's too bad that this is one of the places where the .NET Framework designers decided to limit themselves to what is supported by the O/S, rather than providing an extended implementation that fill out the model to its logical conclusion. A scenario where this would be really useful is when software is running on a server and must format a time according to the conventions appropriate for a remote client - including time zone. #2 - The DateTime class already supports dates that go back before the earliest date that can be represented in any of the Win32 and Ole formats. It goes back to well before the introduction of the Gregorian calendar (which happened around 1750). But it stops, rather arbitrarily, at 1 Jan 1 CE. If you're going back that far, why not support dates BCE up to the limit of the implementation? This limitation makes it impossible to work with dates before year 3761 in the Hebrew calendar. (Actually, the .NET implementation of the Hebrew calendar is even more limited - it only works with dates between years 5343 and 6000). The implementation of DateTime and of date formatting code obviously extends what's available in Win32 or Ole - so why impose these arbitrary limits? Cheers - rick "Michael (michka) Kaplan [MS]" <michkap@online.microsoft.com> wrote in message news:edXWVqDkDHA.3320@tk2msftngp13.phx.gbl... > Hi Rick! Long time no see.... > [quoted text clipped - 28 lines] > > > > - rick cameron "rick cameron" <rick.cameron@decisionscrystal.com> wrote... > #1 - It's too bad that this is one of the places where the .NET Framework > designers decided to limit themselves to what is supported by the O/S, > rather than providing an extended implementation that fill out the model to > its logical conclusion. A scenario where this would be really useful is when > software is running on a server and must format a time according to the > conventions appropriate for a remote client - including time zone. Well, I understand what you are saying here, and I was not on on the team that did this but I think it probably was not based so much on being "as limited as the OS" for no reason, so much as that is what the implementation was doing. Note that they do extend it some, and it ends up causing confusion when the OS and the Framework give two different answers.... > #2 - The DateTime class already supports dates that go back before the > earliest date that can be represented in any of the Win32 and Ole formats. > It goes back to well before the introduction of the Gregorian calendar > (which happened around 1750). But it stops, rather arbitrarily, at 1 Jan 1 > CE. If you're going back that far, why not support dates BCE up to the limit > of the implementation? Well, again I am not on that team so I cannot really explain why. I doubt the reasons are arbitrary, though.... FWIW. > This limitation makes it impossible to work with dates before year 3761 in > the Hebrew calendar. (Actually, the .NET implementation of the Hebrew > calendar is even more limited - it only works with dates between years 5343 > and 6000). Ok, now this is a more reasonable scenario and seems like a much more glaring limitation. I will ask after this one.... > The implementation of DateTime and of date formatting code obviously extends > what's available in Win32 or Ole - so why impose these arbitrary limits? As I said I don't think they are arbitrary limits, but when I have not even seen the code I cannot guess as to the reasoning and/or logic. If I would have to guess I would hazard a speculation that perhaps the code was a port of the oleaut code and the limitation is based on the way that the algorithm was moved over. But I do not know for sure.... SignatureMichKa [MS] NLS Collation/Locale/Keyboard Development Globalization Infrastructure and Font Technologies This posting is provided "AS IS" with no warranties, and confers no rights. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.