Question

有谁知道为什么这种方法有这样的行为？ 2013年不是闰年，所以我希望如果我有一个DateTime对象，如：

    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");

我很感激任何人可能提出的任何意见。

Answer 1

让我根据我从文档和代码中读到的内容尝试答案。

我认为你的时间戳确实是你的想法，即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天。

（我不能完全相信我必须承认这个答案，我想知道Joda中是否存在潜伏的错误。）

无论如何：如果你有UTC时间戳，我可能会建议只使用新的DateTime(stamp, UTC) UTC DateTimeZone个对象。因此，您可以避免令人费解的双区域移位。编辑：此外，如果您的数据库中的标记是真正的UTC，通过使用withZoneRetainFields您更改该标记以表示另一个时间点，这很有可能是错误的方式来做任何你实际尝试做。在日期/时间处理的混乱区域中，以毫秒为单位的时间戳是一个易于理解的项目。如果它不仅仅用于显示目的，我永远不会碰它。

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

1 个答案: