为了进行测试,Web服务器位于具有Maori
文化的计算机上,其短日期格式如下:d/MM/yyyy
。
用户位于具有Hungarian
文化的计算机上,短日期格式为yyyy.MM.dd.
我已经创建了一个网页,在页面加载时会在标签上显示DateTime.Now。显示的日期为2/18/2013 2:22:06 PM
。
所以现在我的问题是,为什么显示的日期是另一种格式/文化,我怀疑是英美?
其次,我需要将数据库中的日期(假设数据库位于具有不同文化的计算机上)与DateTime.Now进行比较。为此,我计划从数据库转换日期以匹配Web服务器的文化。但鉴于第一个问题的情况,我怎么知道DateTime.Now将采用哪种文化/格式?
编辑:使用的代码:
DateTime nowDateTime = DateTime.Now;
Label7.Text = nowDateTime.ToString().Trim();
答案 0 :(得分:5)
对于问题的第一部分:您的代码基本上只是使用当前的线程文化。您可以确保将每个请求的当前线程文化设置为适合该请求的文化(基于接受标头等 - 请参阅HttpRequest.UserLanguages
),或者您可以将其明确传递给所有来电ToString
等等。
至于为什么它以美国英语格式出现 - 这可能是网络服务服务正在运行的文化。这可能与桌面使用的文化不同。如果用户请求不提供任何信息,您应该努力确保不使用,除非可能作为后备。 (我很想选择明确的后备而不是使用服务的默认值。)
其次,我需要将数据库中的日期(假设数据库位于具有不同文化的计算机上)与DateTime.Now进行比较。
使用DateTime.Now
几乎肯定是个坏主意。在大多数情况下,您应该使用DateTime.UtcNow
并在数据库中存储UTC日期/时间。 (在某些情况下,您应该存储本地时间和时区,但即使这样,您也不会使用DateTime.Now
。)
为此,我计划将数据库中的日期转换为与Web服务器的文化相匹配。但鉴于第一个问题的情况,我怎么知道DateTime.Now将采用哪种文化/格式?
在转换为字符串表示形式时,文化主要是相关的。在数据库中存储值或检索数据时,应避免任何此类转换。相反,请确保您在数据库中使用了适当的字段类型(DATETIME
或其他),然后在数据访问层中将其作为DateTime
获取。如果你发现自己试图使用DateTime.Parse
或类似的东西,那应该敲响警钟。您还没有告诉我们您正在使用哪种数据访问技术,但几乎所有内容都允许您直接检索DateTime
。 (例如DbDataReader.GetDateTime
。)
答案 1 :(得分:2)
在比较不同时区的日期时,将其作为UTC存储在数据库中是有意义的。然后,您可以轻松地将其与任何时区的任何其他日期进行比较(再次转换为UTC)。
希望这有帮助。
答案 2 :(得分:1)
根据您的编辑,我不认为文化在相关主题上真的是毛利人。试试这个来测试:
Label7.Text = CultureInfo.CurrentCulture.ToString();
如果是"mi"
或"mi-NZ"
,则是毛利人。 "en"
的内容为英语,"hu"
匈牙利语,等等。
请注意,如果以编程方式更改当前区域性,则仅影响当前线程。不是其他线程。但是您是否尝试在Windows的控制面板中设置区域设置?
答案 3 :(得分:0)
为什么显示的日期是另一种格式/文化,我怀疑是英美?
答案:DateTime.Now
在标签上呈现2/18/2013 2:22:06 PM
已经 英国文化可能是由于当前网络服务器配置或它正在挑选用户的请求文化。Maori
可能的解决方案: 在客户的文化中呈现它,即匈牙利文化
Page
的{{1}}事件,并根据用户的请求更改InitializeCulture
执行Culture
标头{ {1}}应该是类似HttpRequest
以上1点的代码示例
Accept-Language
请参阅Scott Hanselman's Post on Globalisation,其中哪个概念也适用于Web窗体应用程序。
要读取数据库值,请使用代码段,
Accept-Language: hu-HU,en;q=0.8
参考:Format SqlDataReader as date和MSDN - DateTime.Parse Method