gpt4 book ai didi

java - 从 date 到 long 的转换在 java 和 postgresql 中是不一样的

转载 作者:行者123 更新时间:2023-11-29 12:35:45 24 4
gpt4 key购买 nike

我在 postgresql 中有一个表,其中有一列 created_date 日期类型。我创建了以毫秒而不是日期返回日期的 View :

select date_part('epoch'::text, timezone('UTC'::text, created_date::timestamp with time zone)), created_date
from table

这将返回以下结果:

date_part    created_date

1497384000 2017-06-14
1497384000 2017-06-14
1498420800 2017-06-26
1498420800 2017-06-26

在 Java 中我做了以下事情:

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
LocalDate date = LocalDate.parse(view.getStartDate(), formatter);
long longDate = date.atStartOfDay(ZoneId.of("UTC")).toEpochSecond();

2017-06-14 的 longDate 结果为 14973984002017-06-26 的 longDate 结果为 1498435200 .

为什么postgresql和Java从date到long的转换不一样?

PS:数据库的时区是Asia/Baku

最佳答案

您正在调用 atStartOfDay(ZoneId)。由于 ZoneId 是 UTC,因此它将小时设置为午夜,将时区设置为 UTC。因此,您的日期变为 2017-06-14T00:00:00Z,等效的纪元秒值为 1497398400

如果检查数据库返回的值(1497384000):

System.out.println(Instant.ofEpochSecond(1497384000L));

你得到:

2017-06-13T20:00:00Z

如果将其转换为系统正在使用的时区 (Asia/Baku):

System.out.println(Instant.ofEpochSecond(1497384000L).atZone(ZoneId.of("Asia/Baku")));

你得到:

2017-06-14T00:00+04:00[Asia/Baku]

因此,值 1497384000 相当于 UTC 中的 2017-06-13T20:00:00Z。数据库返回 2017-06-14,因为它将此 UTC 日期/时间转换为系统时区(Asia/Baku)。

如果你想得到相同的结果,你必须使用与数据库相同的时区:

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd");
LocalDate date = LocalDate.parse("2017-06-14", formatter);
// using Asia/Baku timezone instead of UTC
long longDate = date.atStartOfDay(ZoneId.of("Asia/Baku")).toEpochSecond();
System.out.println(longDate);

输出将是:

1497384000

关于java - 从 date 到 long 的转换在 java 和 postgresql 中是不一样的,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/44781173/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com