TimeZone and DateTime - what were they thinking?

[rick cameron]

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

[Michael \(michka\) Kaplan [MS]]

Re: TimeZone and DateTime - what were they thinking?

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?


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.


"rick cameron" <rick.cameron@d ecisionscrystal .com> wrote in message
news:%2314w8L5j DHA.2268@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> TimeZone - the only instance you can get is one representing the local[/color]
time[color=blue]
> 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
>
>
>[/color]

[Michael \(michka\) Kaplan [MS]]

Re: TimeZone and DateTime - what were they thinking?

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?


--
MichKa [MS]

This posting is provided "AS IS" with
no warranties, and confers no rights.


"rick cameron" <rick.cameron@d ecisionscrystal .com> wrote in message
news:%2314w8L5j DHA.2268@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> TimeZone - the only instance you can get is one representing the local[/color]
time[color=blue]
> 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
>
>
>[/color]

[rick cameron]

Re: TimeZone and DateTime - what were they thinking?

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:edXWVqDkDH A.3320@tk2msftn gp13.phx.gbl...[color=blue]
> Hi Rick! Long time no see....
>
> For #1, you already know the answer -- it is based on the OS support,[/color]
which[color=blue]
> has this limitation. I do like Michael's SimpleTimeZone, but there are[/color]
still[color=blue]
> issues that are kind of inherent in some of the fundamental instabilities[/color]
of[color=blue]
> 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[/color]
in[color=blue]
> 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[/color]
and[color=blue]
> how you would account for the lack of the actual calendar for the dates[/color]
you[color=blue]
> want to represent?
>
>
> --
> MichKa [MS]
>
> This posting is provided "AS IS" with
> no warranties, and confers no rights.
>
>
> "rick cameron" <rick.cameron@d ecisionscrystal .com> wrote in message
> news:%2314w8L5j DHA.2268@TK2MSF TNGP12.phx.gbl. ..[color=green]
> > TimeZone - the only instance you can get is one representing the local[/color]
> time[color=green]
> > 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
> >
> >
> >[/color]
>
>[/color]

[Kevin Yu [MSFT]]

Re: TimeZone and DateTime - what were they thinking?

Hi Rick,

Generally, we use the B.C. calenders seldomly. So the DateTime structure is
designed for convenience. If you need to represent the A.D. dates you can
try the System.Globaliz ation.Gregorian Calendar class.

Please refer to the following link for more information:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/

frlrfsystemglob alizationgregor iancalendarclas stopic.asp

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

--------------------
| From: "rick cameron" <rick.cameron@d ecisionscrystal .com>
| References: <#14w8L5jDHA.22 68@TK2MSFTNGP12 .phx.gbl>
<edXWVqDkDHA.33 20@tk2msftngp13 .phx.gbl>
| Subject: Re: TimeZone and DateTime - what were they thinking?
| Date: Mon, 13 Oct 2003 21:04:50 -0700
| Lines: 85
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <#6vymggkDHA.24 44@TK2MSFTNGP09 .phx.gbl>
| Newsgroups:
microsoft.publi c.dotnet.framew ork,microsoft.p ublic.dotnet.fr amework.clr,mic r
osoft.public.do tnet.general
| NNTP-Posting-Host: d142-173-9-56.bchsia.telus .net 142.173.9.56
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP09.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.framew ork.clr:8293
microsoft.publi c.dotnet.genera l:111703
microsoft.publi c.dotnet.framew ork:56069
| X-Tomcat-NG: microsoft.publi c.dotnet.genera l
|
| 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:edXWVqDkDH A.3320@tk2msftn gp13.phx.gbl...
| > 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?
| >
| >
| > --
| > MichKa [MS]
| >
| > This posting is provided "AS IS" with
| > no warranties, and confers no rights.
| >
| >
| > "rick cameron" <rick.cameron@d ecisionscrystal .com> wrote in message
| > news:%2314w8L5j DHA.2268@TK2MSF TNGP12.phx.gbl. ..
| > > 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
| > >
| > >
| > >
| >
| >
|
|
|

[rick cameron]

Re: TimeZone and DateTime - what were they thinking?

Hi, Kevin

Thanks for your reply.

Although I don't often need to work with dates BCE myself, occasionally our
customers have requested this.

Another problem that arises from this limit on DateTime is that the
java.util.Date class in J# does not conform to the Java specification, in
that it does not support the range of dates specified.

Cheers

- rick

"Kevin Yu [MSFT]" <v-kevy@online.mic rosoft.com> wrote in message
news:AJOqNLjkDH A.688@cpmsftngx a06.phx.gbl...[color=blue]
> Hi Rick,
>
> Generally, we use the B.C. calenders seldomly. So the DateTime structure[/color]
is[color=blue]
> designed for convenience. If you need to represent the A.D. dates you can
> try the System.Globaliz ation.Gregorian Calendar class.
>
> Please refer to the following link for more information:
>
>[/color]
http://msdn.microsoft.com/library/de...us/cpref/html/[color=blue]
> frlrfsystemglob alizationgregor iancalendarclas stopic.asp
>
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>
> --------------------
> | From: "rick cameron" <rick.cameron@d ecisionscrystal .com>
> | References: <#14w8L5jDHA.22 68@TK2MSFTNGP12 .phx.gbl>
> <edXWVqDkDHA.33 20@tk2msftngp13 .phx.gbl>
> | Subject: Re: TimeZone and DateTime - what were they thinking?
> | Date: Mon, 13 Oct 2003 21:04:50 -0700
> | Lines: 85
> | X-Priority: 3
> | X-MSMail-Priority: Normal
> | X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
> | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
> | Message-ID: <#6vymggkDHA.24 44@TK2MSFTNGP09 .phx.gbl>
> | Newsgroups:
>[/color]
microsoft.publi c.dotnet.framew ork,microsoft.p ublic.dotnet.fr amework.clr,mic r[color=blue]
> osoft.public.do tnet.general
> | NNTP-Posting-Host: d142-173-9-56.bchsia.telus .net 142.173.9.56
> | Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP09.phx.g bl
> | Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.framew ork.clr:8293
> microsoft.publi c.dotnet.genera l:111703
> microsoft.publi c.dotnet.framew ork:56069
> | X-Tomcat-NG: microsoft.publi c.dotnet.genera l
> |
> | Hi again, Michael
> |
> | #1 - It's too bad that this is one of the places where the .NET[/color]
Framework[color=blue]
> | 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[/color]
formats.[color=blue]
> | It goes back to well before the introduction of the Gregorian calendar
> | (which happened around 1750). But it stops, rather arbitrarily, at 1 Jan[/color]
1[color=blue]
> | 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[/color]
in[color=blue]
> | 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:edXWVqDkDH A.3320@tk2msftn gp13.phx.gbl...
> | > 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[/color]
(in[color=blue]
> | > 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[/color]
scenario[color=blue]
> | and
> | > how you would account for the lack of the actual calendar for the[/color]
dates[color=blue]
> | you
> | > want to represent?
> | >
> | >
> | > --
> | > MichKa [MS]
> | >
> | > This posting is provided "AS IS" with
> | > no warranties, and confers no rights.
> | >
> | >
> | > "rick cameron" <rick.cameron@d ecisionscrystal .com> wrote in message
> | > news:%2314w8L5j DHA.2268@TK2MSF TNGP12.phx.gbl. ..
> | > > TimeZone - the only instance you can get is one representing the[/color]
local[color=blue]
> | > 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[/color]
come[color=blue]
> up
> | > > with a good reason for these incredible design restrictions?
> | > >
> | > > Michael Brumm http://michaelbrumm.com has produced a fix for the[/color]
first[color=blue]
> | > > problem with his SimpleTimeZone class - good on you, Michael!
> | > >
> | > > Any thoughts on how to deal with the second problem?
> | > >
> | > > Cheers
> | > >
> | > > - rick cameron
> | > >
> | > >
> | > >
> | >
> | >
> |
> |
> |
>[/color]

[Kevin Yu [MSFT]]

Re: TimeZone and DateTime - what were they thinking?

Hi Rick,

I'm not quite familiar with java. According to the Java Language
Specification from MSDN
(http://msdn.microsoft.com/library/de...-us/vjref98/ht
ml/21_3.asp), we can see that the java.util.Date class might have the same
range as System.DateTime . So it might not support the B.C. dates.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

--------------------
| From: "rick cameron" <rick.cameron@d ecisionscrystal .com>
| References: <#14w8L5jDHA.22 68@TK2MSFTNGP12 .phx.gbl>
<edXWVqDkDHA.33 20@tk2msftngp13 .phx.gbl>
<#6vymggkDHA.24 44@TK2MSFTNGP09 .phx.gbl>
<AJOqNLjkDHA.68 8@cpmsftngxa06. phx.gbl>
| Subject: Re: TimeZone and DateTime - what were they thinking?
| Date: Tue, 14 Oct 2003 09:22:46 -0700
| Lines: 166
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <OFvio9mkDHA.33 12@tk2msftngp13 .phx.gbl>
| Newsgroups: microsoft.publi c.dotnet.genera l
| NNTP-Posting-Host: user.seagatesof tware.com 204.50.113.28
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!tk2 msftngp13.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.genera l:111791
| X-Tomcat-NG: microsoft.publi c.dotnet.genera l
|
| Hi, Kevin
|
| Thanks for your reply.
|
| Although I don't often need to work with dates BCE myself, occasionally
our
| customers have requested this.
|
| Another problem that arises from this limit on DateTime is that the
| java.util.Date class in J# does not conform to the Java specification, in
| that it does not support the range of dates specified.
|
| Cheers
|
| - rick
|
| "Kevin Yu [MSFT]" <v-kevy@online.mic rosoft.com> wrote in message
| news:AJOqNLjkDH A.688@cpmsftngx a06.phx.gbl...
| > Hi Rick,
| >
| > Generally, we use the B.C. calenders seldomly. So the DateTime structure
| is
| > designed for convenience. If you need to represent the A.D. dates you
can
| > try the System.Globaliz ation.Gregorian Calendar class.
| >
| > Please refer to the following link for more information:
| >
| >
|

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/

| > frlrfsystemglob alizationgregor iancalendarclas stopic.asp
| >
| > Kevin Yu
| > =======
| > "This posting is provided "AS IS" with no warranties, and confers no
| > rights."
| >
| > --------------------
| > | From: "rick cameron" <rick.cameron@d ecisionscrystal .com>
| > | References: <#14w8L5jDHA.22 68@TK2MSFTNGP12 .phx.gbl>
| > <edXWVqDkDHA.33 20@tk2msftngp13 .phx.gbl>
| > | Subject: Re: TimeZone and DateTime - what were they thinking?
| > | Date: Mon, 13 Oct 2003 21:04:50 -0700
| > | Lines: 85
| > | X-Priority: 3
| > | X-MSMail-Priority: Normal
| > | X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| > | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| > | Message-ID: <#6vymggkDHA.24 44@TK2MSFTNGP09 .phx.gbl>
| > | Newsgroups:
| >
|
microsoft.publi c.dotnet.framew ork,microsoft.p ublic.dotnet.fr amework.clr,mic r
| > osoft.public.do tnet.general
| > | NNTP-Posting-Host: d142-173-9-56.bchsia.telus .net 142.173.9.56
| > | Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP09.phx.g bl
| > | Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.framew ork.clr:8293
| > microsoft.publi c.dotnet.genera l:111703
| > microsoft.publi c.dotnet.framew ork:56069
| > | X-Tomcat-NG: microsoft.publi c.dotnet.genera l
| > |
| > | 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:edXWVqDkDH A.3320@tk2msftn gp13.phx.gbl...
| > | > 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?
| > | >
| > | >
| > | > --
| > | > MichKa [MS]
| > | >
| > | > This posting is provided "AS IS" with
| > | > no warranties, and confers no rights.
| > | >
| > | >
| > | > "rick cameron" <rick.cameron@d ecisionscrystal .com> wrote in message
| > | > news:%2314w8L5j DHA.2268@TK2MSF TNGP12.phx.gbl. ..
| > | > > 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
| > | > >
| > | > >
| > | > >
| > | >
| > | >
| > |
| > |
| > |
| >
|
|
|

[rick cameron]

Re: TimeZone and DateTime - what were they thinking?

Hi, Kevin

I haven't been able to find a place in the Java specification on Sun's
website where the valid range for Date is mentioned. Nonetheless, the
implementation of the class in the JDK supports BCE dates.

In any case, lack of compatibility with Java is not the main point I'm
trying to make. That point is just this: the TimeZone and DateTime classes
both have arbitrary limits. In the case of TimeZone, this is a real problem
for people trying to write software to run on a server. The documentation
gives no justification for these limits.

I'm sure you don't know the reason for the limits, either. It's buried in
the head of the programmer who designed these classes.

If you can pass on the suggestion that these classes be enhanced in the next
version of the .NET libraries - in particular, that TimeZone support all of
the current time zones, not just the local one, and that DateTime have the
arbitrary limits on its range (1 CE to 9999 CE) removed) I would be very
grateful.

Thanks

- rick

"Kevin Yu [MSFT]" <v-kevy@online.mic rosoft.com> wrote in message
news:XbJARWskDH A.1716@cpmsftng xa06.phx.gbl...[color=blue]
> Hi Rick,
>
> I'm not quite familiar with java. According to the Java Language
> Specification from MSDN
>[/color]
(http://msdn.microsoft.com/library/de...-us/vjref98/ht[color=blue]
> ml/21_3.asp), we can see that the java.util.Date class might have the same
> range as System.DateTime . So it might not support the B.C. dates.
>
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>[/color]

[Kevin Yu [MSFT]]

Re: TimeZone and DateTime - what were they thinking?

Hi Rick,

I will pass your suggestion through an appropriate channel. Thank you very
much for your advice!

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

--------------------
| From: "rick cameron" <rick.cameron@d ecisionscrystal .com>
| References: <#14w8L5jDHA.22 68@TK2MSFTNGP12 .phx.gbl>
<edXWVqDkDHA.33 20@tk2msftngp13 .phx.gbl>
<#6vymggkDHA.24 44@TK2MSFTNGP09 .phx.gbl>
<AJOqNLjkDHA.68 8@cpmsftngxa06. phx.gbl>
<OFvio9mkDHA.33 12@tk2msftngp13 .phx.gbl>
<XbJARWskDHA.17 16@cpmsftngxa06 .phx.gbl>
| Subject: Re: TimeZone and DateTime - what were they thinking?
| Date: Wed, 15 Oct 2003 09:29:28 -0700
| Lines: 43
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
| Message-ID: <#TwRCmzkDHA.37 00@TK2MSFTNGP11 .phx.gbl>
| Newsgroups: microsoft.publi c.dotnet.genera l
| NNTP-Posting-Host: user.seagatesof tware.com 204.50.113.28
| Path: cpmsftngxa06.ph x.gbl!TK2MSFTNG P08.phx.gbl!TK2 MSFTNGP11.phx.g bl
| Xref: cpmsftngxa06.ph x.gbl microsoft.publi c.dotnet.genera l:112003
| X-Tomcat-NG: microsoft.publi c.dotnet.genera l
|
| Hi, Kevin
|
| I haven't been able to find a place in the Java specification on Sun's
| website where the valid range for Date is mentioned. Nonetheless, the
| implementation of the class in the JDK supports BCE dates.
|
| In any case, lack of compatibility with Java is not the main point I'm
| trying to make. That point is just this: the TimeZone and DateTime classes
| both have arbitrary limits. In the case of TimeZone, this is a real
problem
| for people trying to write software to run on a server. The documentation
| gives no justification for these limits.
|
| I'm sure you don't know the reason for the limits, either. It's buried in
| the head of the programmer who designed these classes.
|
| If you can pass on the suggestion that these classes be enhanced in the
next
| version of the .NET libraries - in particular, that TimeZone support all
of
| the current time zones, not just the local one, and that DateTime have the
| arbitrary limits on its range (1 CE to 9999 CE) removed) I would be very
| grateful.
|
| Thanks
|
| - rick
|
| "Kevin Yu [MSFT]" <v-kevy@online.mic rosoft.com> wrote in message
| news:XbJARWskDH A.1716@cpmsftng xa06.phx.gbl...
| > Hi Rick,
| >
| > I'm not quite familiar with java. According to the Java Language
| > Specification from MSDN
| >
|
(http://msdn.microsoft.com/library/de...-us/vjref98/ht
| > ml/21_3.asp), we can see that the java.util.Date class might have the
same
| > range as System.DateTime . So it might not support the B.C. dates.
| >
| > Kevin Yu
| > =======
| > "This posting is provided "AS IS" with no warranties, and confers no
| > rights."
| >
|
|
|

[Michael \(michka\) Kaplan [MS]]

Re: TimeZone and DateTime - what were they thinking?

"rick cameron" <rick.cameron@d ecisionscrystal .com> wrote...
[color=blue]
> #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[/color]
to[color=blue]
> its logical conclusion. A scenario where this would be really useful is[/color]
when[color=blue]
> software is running on a server and must format a time according to the
> conventions appropriate for a remote client - including time zone.[/color]

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....
[color=blue]
> #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[/color]
limit[color=blue]
> of the implementation?[/color]

Well, again I am not on that team so I cannot really explain why. I doubt
the reasons are arbitrary, though.... FWIW.
[color=blue]
> 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[/color]
5343[color=blue]
> and 6000).[/color]

Ok, now this is a more reasonable scenario and seems like a much more
glaring limitation. I will ask after this one....
[color=blue]
> The implementation of DateTime and of date formatting code obviously[/color]
extends[color=blue]
> what's available in Win32 or Ole - so why impose these arbitrary limits?[/color]

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....


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.