DateTime getDayOfYear（）返回366为12-31-2013而不是365

有谁知道为什么这种方法的行为是这样吗？ 2013是不是闰年，所以我希望，如果我有一个DateTime对象，如：DateTime getDayOfYear（）返回366为12-31-2013而不是365

DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss");   
    DateTime dt = formatter.parseDateTime("2013-12-31 23:59:52");

这

dt.getDayOfYear()

会给我365，但它给了我366.有人能看到什么问题是？我也越来越366，如果我做

dt.toString("DDD");

我将不胜感激任何输入任何可能。

来源

2014-01-22 Lani1234

它给了我365. –

这可能是一个时区问题，在这种情况下我们需要@JonSkeet。 – Sinkingpoint

如果你发布你的时区，这将是一件好事。 –

让我试着根据我从文档和代码中读取的内容做出答案。

我假设你的时间戳确实是你认为的，也就是2013 UTC的最后一刻。

您在默认时区中创建了一个DateTime对象，其中邮戳为。所以如果你的本地时区是+01：00，这是2013-14-01 00:59 +01:00。

现在您使用withZoneRetainFields(UTC)。从文档我明白，这改变了毫秒，使他们实际上反映2014-01-01 00:59 UTC，基本上这需要添加3600 * 1000毫秒的时间戳，同时将对象的时区条目更改为UTC。

当你再问问全年的那一天，究竟发生了内部是

.dayOfYear().get(getMillis())

我的预感是dayOfYear仍是基于2013年和从这个底线你得到一天366

（我不完全相信我自己这个答案，我必须承认，我不知道是否可能只是潜伏在乔达的一个bug。）

无论如何：如果你有UTC时间戳，我可能会建议只使用新的DateTime(stamp, UTC)其中UTC a DateTimeZone对象。从而避免了令人费解的双重区域转移。编辑：此外，如果你从DB的邮票是真正的UTC，通过使用withZoneRetainFields你改变这张邮票来表示另一个时间点，这是一个很好的机会做错任何你想做的事情。在日期/时间处理的混淆区域，millis中的时间戳是一个易于理解的项目。如果它不只是为了显示目的，我绝不会碰它。

来源

2014-01-22 21:05:56 Harald

谢谢@Harald。如果事实上发生了什么，这确实会让它神秘化。我至少会尝试你最后的建议，看看它是否会以任何方式改变结果（我会发布我得到的结果）。我在想自己是否有潜伏在乔达的虫子。 – Lani1234

谢谢@Harald。刚看到你的编辑。我正在获得一个新的谜团。我想在12/25/2013获得每一分钟的时间。除了第1140-1154分钟（全天19小时）之外，一切都很好。他们每个休息一天。因此，对于第1139分钟，我有纪元时间1388015940，这是正确的。然后分钟1140跳到1387929600.从1140-1154，他们增加了60秒，这是正确的，但全部关闭了一天。然后在1155分钟，他们回到1388016900的正确时间。你能想到这个的任何理由吗？ – Lani1234

从你写日期的方式来看，我想你现在住在美国。从19小时的奇怪行为，我进一步猜测你处于-05：00时区，东部地区。显然，你不知何故发现了本地日期/时间对象的行为。请考虑只创建具有已在构造函数中指定的特定时区的DateTime对象。 – Harald

DateTime getDayOfYear（）返回366为12-31-2013而不是365

回答

相关问题