如果我写一个简单的方法来返回纪元时间和DateTime.UtcNow
之间的毫秒数,我会得到一个正确的答案。但是,如果我编写一个方法来返回某个任意日期和纪元时间之间的毫秒数,则最后三位数字始终为零。 '某些任意日期'意味着我将DateTime.Parse的输出传递给该方法(“任意日期字符串”)。尽可能接近,.Parse返回的DateTime对象并没有返回所有有效数字。
测试方法:
static void GetMillis()
{
DateTime dUtc = DateTime.UtcNow;
DateTime epoch = new DateTime(1970,1,1,0,0,0,DateTimeKind.Utc);
double utcmillis = (dUtc - epoch).TotalMilliseconds;
String timestamp = dUtc.ToString();
DateTime arbitrary = (DateTime.Parse(timestamp));
Console.WriteLine("Milliseconds between DateTime.UtcNow {0} \nand epoch time {1} are {2}", dUtc, epoch, utcmillis);
Console.WriteLine("Milliseconds between arbitrary date {0} \nand epoch time {1} are {2}", arbitrary, epoch, (arbitrary - epoch).TotalMilliseconds);
}
输出:
C:\src\vs\epochConverter\epochConverter\bin\Debug
{powem} [54] --> .\epochConverter.exe -debug
Milliseconds between DateTime.UtcNow 8/26/2012 11:12:31 PM
and epoch time 1/1/1970 12:00:00 AM are 1346022751385.8
Milliseconds between arbitrary date 8/26/2012 11:12:31 PM
and epoch time 1/1/1970 12:00:00 AM are 1346022751000
我不知道我是在做一些奇怪的错误还是不在这里理解数学。我在MSDN上研究过,找不到与这种差异有关的任何内容。我真的希望能够按照描述计算毫秒数 - 是否可能?
感谢。
熔点
答案 0 :(得分:2)
您想要检查以下的中间值:
String timestamp = dUtc.ToString();
它返回的内容取决于您的本地设置,但它类似8/26/2012 11:12:31
,只能精确到最接近的秒数。
解析当然会给出一个0毫秒的日期时间。
因此,你的milliseconds-since-epoch方法在那时为零是正确的。
但是如果你做了类似的事情:
arbitrary = new DateTime(2012, 8, 26, 11, 12, 31, 123);
您将获得影响结果的123毫秒。您还可以使用ToString
和ParseExact
,其中包含一秒或几小段其他获取DateTime的方法。
总而言之,你的毫秒 - 自上世纪以来完美无缺,但是你的日期测试方式存在缺陷。
答案 1 :(得分:1)
默认DateTime.ToString()
格式不包括毫秒,这是数据丢失的地方;它发生在之前 Parse
。要获取字符串表示中的毫秒数,请使用自定义格式:
DateTime.UtcNow.ToString()
// -> 8/26/2012 11:37:24 PM
DateTime.Parse("8/26/2012 11:37:24 PM").Millisecond
// -> 0
DateTime.UtcNow.ToString("yyyy-MM-ddTHH:mm:ss.fffffffK")
// -> 2012-08-26T23:41:17.3085938Z
DateTime.Parse("2012-08-26T23:41:17.3085938Z").Millisecond
// -> 308
请参阅The Round-trip ("O", "o") Format Specifier 以输入less。或者,在这种情况下,请考虑完全避免转换: - )
数学是合理的。
答案 2 :(得分:0)
这里的数学看起来很合理。不要忘记1秒钟内有1000毫秒,因此从任意时间开始的任何日期计算(包括毫秒)与几乎相同的时间(包括毫秒)都会产生+/- 1000毫秒的误差。