TimeZone和DateTime - 他们在想什么？ [英] TimeZone and DateTime - what were they thinking?

问题描述

TimeZone - 唯一可以获得的实例是代表当地时间的实例

区域

DateTime - 不能代表00:00:00之前的时间1月1日CE


他们在想什么？这是一个严肃的问题 - 任何人都可以提出这些令人难以置信的设计限制吗？


Michael Brumm http://michaelbrumm.com 使用他的SimpleTimeZone类产生了第一个

问题的修复 - 擅长你，迈克尔！


关于如何处理第二个问题的任何想法？


干杯


- rick cameron

解决方案

嗨瑞克！好久不见....


对于＃1，你已经知道了答案 - 它是基于操作系统的支持，

有这个局限性。我确实喜欢迈克尔的SimpleTimeZone，但仍然存在

问题，这些问题在整个时区的某些基本不稳定性中是固有的。最重要的一点是Michael自己

建议总是使用UTC然后转换为当地时间进行显示

- 这是MS从一开始就提倡的，是什么他们使用

AD和电子邮件，实际上是什么导致SimpleTimeZone能够（在大多数情况下为
）从需求到可选的酷炫功能。


对于＃2，在日历存在之前很难理解格里高利历日期的含义

。也许你可以解释实际情况和

你如何解释你想要代表的日期的实际日历的缺失？

-

MichKa [MS]


此帖子按原样提供。与

无保证，并且不授予任何权利。

" rick cameron" < RI ********** @ decisionscrystal.com>在消息中写道

新闻：％2 **************** @ TK2MSFTNGP12.phx.gbl ...

TimeZone - 唯一可以获得的实例是代表当地
时区的实例
DateTime - 不能代表公元1月1日00:00:00之前的时间

他们在想什么？这是一个严肃的问题 - 任何人都可以提出这些令人难以置信的设计限制吗？

Michael Brumm http://michaelbrumm.com 用他的SimpleTimeZone课程解决了第一个问题 - 对你好，迈克尔！

有关如何处理第二个问题的任何想法吗？

- rick cameron

嗨瑞克！好久不见....


对于＃1，你已经知道了答案 - 它是基于操作系统的支持，

有这个局限性。我确实喜欢迈克尔的SimpleTimeZone，但仍然存在

问题，这些问题在整个时区的某些基本不稳定性中是固有的。最重要的一点是Michael自己

建议总是使用UTC然后转换为当地时间进行显示

- 这是MS从一开始就提倡的，是什么他们使用

AD和电子邮件，实际上是什么导致SimpleTimeZone能够（在大多数情况下为
）从需求到可选的酷炫功能。


对于＃2，在日历存在之前很难理解格里高利历日期的含义

。也许你可以解释实际情况和

你如何解释你想要代表的日期的实际日历的缺失？

-

MichKa [MS]


此帖子按原样提供。与

无保证，并且不授予任何权利。

" rick cameron" < RI ********** @ decisionscrystal.com>在消息中写道

新闻：％2 **************** @ TK2MSFTNGP12.phx.gbl ...

TimeZone - 唯一可以获得的实例是代表当地
时区的实例
DateTime - 不能代表公元1月1日00:00:00之前的时间

他们在想什么？这是一个严肃的问题 - 任何人都可以提出这些令人难以置信的设计限制吗？

Michael Brumm http://michaelbrumm.com 用他的SimpleTimeZone课程解决了第一个问题 - 对你好，迈克尔！

有关如何处理第二个问题的任何想法吗？

- rick cameron

嗨再次，迈克尔


＃1 - 这是一个非常糟糕的地方，这是.NET Framework的地方之一

设计师决定将自己限制在O / S支持的范围内，而不是提供一个扩展的实现，将模型填写为逻辑结论。这将非常有用的场景是当服务器上运行

软件时，必须根据适用于远程客户端的

约定格式化时间 - 包括时区。


＃2 - DateTime类已经支持在

最早日期之前返回的日期，可以用任何Win32和Ole格式表示。

它可以追溯到公历引入之前

（发生在1750年左右）。但它在1月1日停止，相当随意，

CE。如果你回到那么远，为什么不支持BCE的日期达到极限

的实施？


这个限制使它无法工作在3761年之前的日期在

希伯来日历。 （实际上，希伯来语

日历的.NET实现更加有限 - 它仅适用于5343年之间的日期

和6000）。


DateTime和日期格式代码的实现显然扩展了

Win32或Ole中可用的内容 - 那么为什么要施加这些任意限制？


干杯


- rick


" Michael（michka）Kaplan [MS]" < MI ***** @ online.microsoft.com>写在

消息新闻：ed ************** @ tk2msftngp13.phx.gbl ...

嗨里克！好久不见....

对于＃1，你已经知道了答案 - 它基于操作系统支持，
有这个限制。我确实喜欢迈克尔的SimpleTimeZone，但还有一些
仍然存在问题，这些问题在一些基本不稳定因素中是固有的。最重要的一点是迈克尔自己建议总是使用UTC然后转换为当地时间进行显示
- 这是MS从一开始就提倡的，他们在AD中使用
和电子邮件，以及实际上导致SimpleTimeZone能够（在大多数情况下）从需求到可选的酷炫功能的原因。
对于＃2，很难理解Gregorian的含义日历日期
日历存在之前。也许您可以解释实际情况
以及如何解释您想要代表的日期
缺少实际日历？

-
MichKa [MS]

此帖子按原样提供。没有保证，也没有授予任何权利。

" rick cameron" < RI ********** @ decisionscrystal.com>在消息中写道
新闻：％2 **************** @ TK2MSFTNGP12.phx.gbl ...

TimeZone - 唯一的实例你可以获得的是一个代表本地的

时间

区域
日期时间 - 不能代表公元前1月1日00:00:00之前的时间
<他们在想什么？这是一个严肃的问题 - 任何人都可以提出这些令人难以置信的设计限制吗？

Michael Brumm http://michaelbrumm.com 用他的SimpleTimeZone课程解决了第一个问题 - 对你好，迈克尔！

有关如何处理第二个问题的任何想法吗？

- 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

解决方案

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" <ri**********@decisionscrystal.com> wrote in message
news:%2****************@TK2MSFTNGP12.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

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" <ri**********@decisionscrystal.com> wrote in message
news:%2****************@TK2MSFTNGP12.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

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]" <mi*****@online.microsoft.com> wrote in
message news:ed**************@tk2msftngp13.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" <ri**********@decisionscrystal.com> wrote in message
news:%2****************@TK2MSFTNGP12.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

这篇关于TimeZone和DateTime - 他们在想什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！