我们正在为web服务客户端开发一个c#应用程序。这将在Windows XP PC上运行。
web服务返回的字段之一是DateTime字段。服务器返回一个GMT格式的字段，即结尾有一个“Z”。
然而，我们发现。net似乎做了某种隐式转换，而且时间总是12小时。
下面的代码示例在一定程度上解决了这个问题，因为12小时的差异已经消失，但它不考虑新西兰的夏令时。
CultureInfo ci = new CultureInfo("en-NZ");
string date = "Web service date".ToString("R", ci);
DateTime convertedDate = DateTime.Parse(date);
根据这个约会网站:
UTC / GMT抵消 标准时区:UTC/GMT +12小时 夏令时:+1小时 当前时区偏移:UTC/GMT +13小时
我们如何调整额外的一小时?这可以通过编程来完成吗?或者这是PC上的某种设置吗?
当前回答
我会考虑使用这套系统。TimeZoneInfo类，如果你在。net 3.5。见http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx。这应该正确地考虑到夏时制的变化。
// Coordinated Universal Time string from
// DateTime.Now.ToUniversalTime().ToString("u");
string date = "2009-02-25 16:13:00Z";
// Local .NET timeZone.
DateTime localDateTime = DateTime.Parse(date);
DateTime utcDateTime = localDateTime.ToUniversalTime();
// ID from:
// "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Time Zone"
// See http://msdn.microsoft.com/en-us/library/system.timezoneinfo.id.aspx
string nzTimeZoneKey = "New Zealand Standard Time";
TimeZoneInfo nzTimeZone = TimeZoneInfo.FindSystemTimeZoneById(nzTimeZoneKey);
DateTime nzDateTime = TimeZoneInfo.ConvertTimeFromUtc(utcDateTime, nzTimeZone);
其他回答
我只是想补充一个一般性的警告。
如果你所做的只是从计算机内部时钟获取当前时间，然后将日期/时间显示在显示器或报告上，那么一切都很好。但是如果您正在保存日期/时间信息以供以后参考，或者正在计算日期/时间，请小心!
Let's say you determine that a cruise ship arrived in Honolulu on 20 Dec 2007 at 15:00 UTC. And you want to know what local time that was. 1. There are probably at least three 'locals' involved. Local may mean Honolulu, or it may mean where your computer is located, or it may mean the location where your customer is located. 2. If you use the built-in functions to do the conversion, it will probably be wrong. This is because daylight savings time is (probably) currently in effect on your computer, but was NOT in effect in December. But Windows does not know this... all it has is one flag to determine if daylight savings time is currently in effect. And if it is currently in effect, then it will happily add an hour even to a date in December. 3. Daylight savings time is implemented differently (or not at all) in various political subdivisions. Don't think that just because your country changes on a specific date, that other countries will too.
我遇到了这个问题，因为我有一个UTC日期的问题，你通过twitter API (created_at字段的状态);我需要将它们转换为DateTime。本页上的答案/代码示例中的答案都不足以阻止我得到“字符串不被识别为有效的DateTime”错误(但这是我在SO上找到正确答案的最接近的答案)
在这里发布这个链接，以防这有助于其他人-我需要的答案在这篇博客文章中找到:http://www.wduffy.co.uk/blog/parsing-dates-when-aspnets-datetimeparse-doesnt-work/ -基本上使用DateTime。ParseExact使用格式字符串代替DateTime。解析
DateTime对象默认具有未指定的Kind，为了ToLocalTime的目的，它被假定为UTC。
要获得一个未指定的DateTime对象的本地时间，你只需要这样做:
convertedDate.ToLocalTime();
将DateTime的Kind从Unspecified更改为UTC这一步是不必要的。为了ToLocalTime: http://msdn.microsoft.com/en-us/library/system.datetime.tolocaltime.aspx的目的，Unspecified被假定为UTC
该代码块使用通用时间转换当前DateTime对象，然后将其转换回本地DateTime。对我来说是完美的，我希望它能帮助到你!
CreatedDate.ToUniversalTime().ToLocalTime();
我知道这是一个老问题，但我遇到过类似的情况，我想分享我的发现给未来的搜索者，可能包括我自己:)。
DateTime.Parse()可能很棘手——参见这里的例子。
如果DateTime来自Web服务或其他具有已知格式的源，则可能需要考虑类似于
DateTime.ParseExact(dateString,
"MM/dd/yyyy HH:mm:ss",
CultureInfo.InvariantCulture,
DateTimeStyles.AssumeUniversal | DateTimeStyles.AdjustToUniversal)
或者更好的是，
DateTime.TryParseExact(...)
AssumeUniversal标志告诉解析器日期/时间已经是UTC;AssumeUniversal和adjusttuniversal的组合告诉它不要将结果转换为“本地”时间，默认情况下它会尝试这样做。(无论如何，我个人尝试在业务/应用程序/服务层专门处理UTC。但跳过转换到本地时间也会加快速度——在我的测试中，速度加快了50%或更多，见下文。)
这是我们之前所做的:
DateTime.Parse(dateString, new CultureInfo("en-US"))
我们对这款应用进行了分析，发现DateTime。解析占CPU使用的很大比例。(顺便提一下，CultureInfo构造函数并不是CPU使用的重要贡献者。)
所以我设置了一个控制台应用程序，以各种方式解析日期/时间字符串10000次。底线: Parse() 10秒 ParseExact()(转换为本地)20-45毫秒 ParseExact()(不转换为本地)10-15毫秒 ．.． 是的，Parse()的结果是以秒为单位的，而其他的是以毫秒为单位的。
