最近，java中的偏移量和时区

所以，我做了下面的例子：

public class Test { 
    public static void main(String[] args) { 

     System.out.println(Instant.now().getEpochSecond()); 
     System.out.println(new Date().getTime()); 
     System.out.println(LocalDateTime.now().atZone(ZoneId.systemDefault()).toEpochSecond()); 
     System.out.println(LocalDateTime.now().toEpochSecond(ZoneOffset.UTC)); 

     System.out.println(ZoneId.systemDefault().toString()); 
    } 
}

输出是：

1460651620 
1460651620182 
1460651620 
1460662420 
Europe/Helsinki

我现在systemDefault是了zoneid欧洲/赫尔辛基（+3小时）
当我们创建new Date()它有unix时间戳（UTC）。

这是我比较印刷结果的基础。

1.在我的第三个System.out我有LocalDateTime与已建立的时区systemDefault但输出实际上是相同的。我预计更大的价值（+3小时）。

2.在第四个输出行我虽然有混乱的结果。我期望与new Date().getTime()相同的值

需要一些帮助来理解输出。

来源

2016-04-14 Alex Silkovsky

getEpochSecond()和toEpochSecond()类型的任何方法都会为您提供自1970-01-01T00:00:00Z时期以来的秒数，无论时区如何，时间的运行方式都是相同的，因此无论选择哪个时区，结果都是相同的。

假设你花了10分钟在你的时区写这个问题，它将在我的时区相同的10分钟。

来源

2016-04-14 17:13:56

我有既定的时区的LocalDateTime systemDefault

不，你不知道。你从LocalDateTime开始，但是随后你将它转换为ZonedDateTime。 A ZonedDateTime实际上是LocalDateTime，其中ZoneId和UTC的偏移量用于处理歧义。

LocalDateTime没有toEpochSecond()方法，因为它不代表一个固定的时间点。它具有toEpochSecond(ZoneOffset)，因为通过应用UTC偏移量将本地日期/时间“锚定”到固定时间点。

相比之下，与ZonedDateTime其中确实有无参数toEpochSecond()方法，因为它代表在固定时间点，与一个时间区的附加上下文。（您可以查看ZonedDateTime为Instant有ZoneId，或用ZoneId一个LocalDateTime和ZoneOffset;他们是等价的，但我个人更喜欢后者的概念）

请注意，您的代码可能给予你会得到一个不同的结果 - 如果你处于LocalDateTime.now()由于时钟回退（通常在夏令时结束）而不明确的时段。在这种情况下，LocalDateTime.atZone选择较早出现的那个LocalDateTime，而实际上您可能正在经历后面的事件。这是LocalDateTime.now().atZone(zone)和ZonedDateTime.now(zone)之间的差异 - 后者将始终“正确”知道偏移量。

来源

2016-04-14 18:00:11

最近，java中的偏移量和时区

回答

相关问题