Question

建立了一个基本系统，允许用户在某个日期/时间安排与人A，B，C的会议。

我想要理智地检查我们的解决方案是否适用于DST更改。

两个关键类是：

User - 保留用户ZoneId以及Europe/Paris，Asia/Tokyo等。
Event - 保留预定事件的LocalDateTime例如。事件创建时的2018-05-04T10:00:00.000和用户的ZoneId例如。 Europe/Paris。

然后我们将事件粘贴在我们的调度程序中：

import org.springframework.scheduling.TaskScheduler;
import java.time.Instant;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.time.temporal.ChronoUnit;
import java.util.Date;

public class MyScheduler {

    private final TaskScheduler executor;

    ...

    public void schedule(Event event) {
        ...
        ZonedDateTime scheduledAt = ZonedDateTime.of(event.getScheduledAt(), event.getScheduledAtTimeZone());
        if (scheduledAt.isAfter(ZonedDateTime.now(ZoneId.systemDefault()))) {
            executor.schedule(task, Date.from(scheduledAt.toInstant()));
        }
    }
}

如果我纠正了上述代码，无论时钟是UTC + 1还是UTC + 2，都应该在周五上午10点Europe/Paris启动事件集。

上述方法是否显得健全？

我还注意到ZonedDateTime类除了时间和区域之外还有一个偏移量，例如。 2018-05-02T20:46:03.002+01:00[Europe/London]。保持偏移量的唯一原因（我能想到）是知道用户是否在夏令时期间创建了事件。

在这种情况下，我们的系统存储偏移是否有任何好处，或者我们只对本地事件时间及其创建的区域有好处吗？

Answer 1

我能想到的唯一真正的问题是，当时钟向后移动时，事件发生在秋季时，即使知道区域，LocalDateTime也可能是模糊的。

Instant通常建议用于时区中性点，因此除非严格要求了解创建事件的时区，否则我会使用此方法。即使是一项要求，因为您仍然可以将ZoneId放在旁边。它还可以使您的代码更简单。另一个理智的选择是预定时间ZonedDateTime;它对我的吸引力较小。

支持跨时区和夏令时更改的重复活动

1 个答案: