Java API 和客户端应用程序 - 如何正确处理时区

Question

我正在开发一个 Android 应用程序正在使用的 Java API。我已经到了需要考虑时区正确处理日期和时间的地步。

该应用程序的功能之一是预订某种指定日期和时间的服务。用户可以取消预订，如果在预订开始前 24 小时取消预订，客户将获得全部退款。

现在假设服务器位于伦敦 (gmt 0)，用户位于西类牙 (gmt +1)，并且预订于 2015 年 2 月 25 日 16:00:00 开始。

当用户取消预订时，服务器需要区分 NOW() 和预订开始日期。因此，如果用户(西类牙)在 2015 年 2 月 24 日 17:00:00(西类牙时间，预订前 23 小时；因此他不会获得全额退款)取消预订当服务器检查差异时，因为NOW(英国是16:00:00)结果将是24小时，因此会错误地全额退款。

我的问题就在这里。如何根据用户时区正确获得正确的小时数？我不太满意在取消请求中发送客户端时区，因为该值很容易被用户欺骗。

在服务器端存储日期和时间时，什么是好的做法？我应该将它们存储在服务器时间中并使用额外的字段来了解客户端时区偏移吗？

Answer 1

Answer by Baranauskas是正确的。

在 UTC 工作

一般来说，你所有的业务逻辑、数据交换、数据存储和序列化，都应该在UTC中完成。 。仅在需要/预期时应用时区，例如向用户演示。

java.time

一定要使用 Java 8 及更高版本中内置的 java.time 框架。

默认情况下，java.time 类使用标准 ISO 8601用于解析/生成日期时间值的文本表示的格式。否则使用 DateTimeFormatter 对象。

Local… 类型是通用的，不适用于任何地点，没有时区或 offset-from-UTC 。通常不在商业应用程序中使用，因为它们不是时间线上的实际时刻。此处用于分别解析日期字符串和时间字符串，组合并应用西类牙的已知时区。这样做会产生一个 ZonedDateTime，即时间轴上的实际时刻。

LocalDate dateBooking = LocalDate.parse ( "2016-02-25" ); // Parses strings in standard ISO 8601 format.
LocalTime timeBooking = LocalTime.parse ( "16:00:00" );
LocalDateTime localBooking = LocalDateTime.of ( dateBooking , timeBooking );
ZoneId zoneId = ZoneId.of ( "Europe/Madrid" );
ZonedDateTime zonedBooking = localBooking.atZone ( zoneId );

从中我们可以提取 Instant ，UTC 时间线上的一个时刻。

Instant booking = zonedBooking.toInstant ();

计算取消订单所需的 24 小时通知时间。请注意，24 小时与“一天”不同，因为由于夏令时 (DST) 等异常情况，日子的长度会有所不同。

Instant twentyFourHoursEarlier = booking.minus ( 24 , ChronoUnit.HOURS );

获取用户正在取消的当前时刻。这里我们使用问题中指定的日期时间进行模拟。对于较短的代码，我们调整一个小时，因为此解析方法仅处理 UTC (Z) 字符串。该问题指出西类牙时间 17:00； 欧洲/马德里 比 UTC 早一小时，因此我们减去 16:00Z 一个小时。

Instant cancellation = Instant.parse ( "2016-02-24T16:00:00Z" );  // 17:00 in Europe/Madrid is 16:00Z.
//  Instant cancellation = Instant.now ();  // Use this in real code.

通过调用isBefore来比较Instant对象或isAfter方法。

Boolean cancelledEarlyEnough = cancellation.isBefore ( twentyFourHoursEarlier );

Duration 将时间跨度表示为总秒数加上以纳秒为单位的秒数。我们在这里使用它来帮助进行数学计算，验证我们得到了 23 小时的预期结果。 toString 方法使用标准 ISO 8601 durations format PT23H，其中 P 标记开始，T 将年-月-日部分与时-分-秒部分分开， H 表示“小时”。

Duration cancellationNotice = Duration.between ( cancellation , booking );

转储到控制台。

System.out.println ( "zonedBooking: " + zonedBooking + " | booking: " + booking + " | twentyFourHoursEarlier: " + twentyFourHoursEarlier + " | cancellation: " + cancellation + " | cancelledEarlyEnough: " + cancelledEarlyEnough + " | cancellationNotice: " + cancellationNotice );

zonedBooking: 2016-02-25T16:00+01:00[Europe/Madrid] | booking: 2016-02-25T15:00:00Z | twentyFourHoursEarlier: 2016-02-24T15:00:00Z | cancellation: 2016-02-24T16:00:00Z | cancelledEarlyEnough: false | cancellationNotice: PT23H

通过应用他们想要/预期的时区来呈现给用户。指定 Instant 和 ZoneId 以获取 ZonedDateTime。

ZoneId zoneId_Presentation = ZoneId.of( "Europe/Madrid" );
ZonedDateTime zdtBooking = ZonedDateTime.ofInstant( booking , zoneId_Presentation );
ZonedDateTime zdtCancellationGrace = ZonedDateTime.ofInstant( twentyFourHoursEarlier , zoneId_Presentation );
ZonedDateTime zdtCancellation = ZonedDateTime.ofInstant( cancellation , zoneId_Presentation );

通过为人类语言指定短-中-长标志和 Locale 来让 java.time 为您进行本地化，以在其中 (a) 翻译日/月名称，(b) 使用日期时间部分排序、选择逗号与句点等的文化规范。

DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL );
formatter = formatter.withLocale( new Locale("es", "ES") );
String output = zdtBooking.format( formatter );

jueves 25 de febrero de 2016 16H00' CET

忽略服务器时区

您的问题提到了服务器的时区。您永远不应该依赖服务器的时区，因为它超出了您作为程序员的控制范围，并且系统管理员无需多想就可以轻松更改它。此外，您的 JVM 当前的默认时区可能基于主机操作系统的时区。但不一定。 JVM 命令行启动时的标志可以设置 JVM 的默认时区。更危险的是:JVM 内任何应用程序的任何线程上的任何代码都可以设置时区并立即影响您的应用程序 - 在运行时!

如果不指定时区，则隐式应用 JVM 的当前默认值。始终明确指定您想要/预期的时区，如上面的代码所示。

以上内容也适用于当前默认的区域设置。始终指定所需/预期的区域设置，而不是隐式依赖 JVM 当前的默认值。