我有一个能耗事实表，如下所示：
f_meter_data:
utc_calendar_id
local_calendar_id
meter_id
reading
timestamp
日历表是根据 Kimball 建议构建的，正是数据仓库工具包中的建议是我拥有两个日历 ID 的原因，以便用户可以查询本地时间和 UTC 时间。
这一切都很好，但是当夏令时开始时问题就出现了。
由于粒度为半小时周期，时钟变化时会有重复的事实记录。
当时钟向另一个方向变化时，数据中就会出现间隙。
我该如何处理这种情况？
我应该平均重复值并存储它吗？
当它是数据的差距时，我应该使用差距之前的点和差距之后的点的平均值吗？
我有一种感觉，这个问题最终可能会因为“主要基于意见”而被关闭，但我的特别意见是，应该设置系统来处理并非每天都有 24 小时这一事实。可能有 23、24 或 25。（或者，如果您在豪勋爵岛，则为 23.5、24 或 24.5）。
根据您的额外时间何时下降（每个时区会有所不同），您可能会遇到以下情况：
00 01a 01b 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
或者您可以考虑将小时与本地 UTC 偏移量结合起来，例如：
00-04:00 01-04:00 01-05:00 02-05:00 03-05:00 etc...
或者，如果您正在做半小时的水桶：
00:00-04:00 00:30-04:00 01:00-04:00 01:30-04:00 01:00-05:00 01:30-05:00 ...
进行任何平均以对齐 24 小时可能不合适。如果你这样做了，那么总数就会关闭。
您还应该考虑人们将如何使用这些数据。他们会试图找出一天中给定时间的趋势吗？如果是这样，那么它们将如何补偿由 DST 过渡引起的尖峰或下降？它可能就像在输出报告上添加星号和脚注一样简单。或者它可能比这更复杂，具体取决于使用情况。
另外，您说您的工作间隔为 30 分钟。请注意，有些时区相差 45 分钟（尼泊尔、查塔姆群岛和澳大利亚的一个小区域）。因此，如果您想覆盖整个世界，那么您将需要 15 分钟的间隔桶。
而且，正如Whichert 在评论中指出的那样，如果您使用的是UTC，那么就没有夏令时。只有当您按当地时间分组时，您才会有这种担忧。
您可能还会发现DST 标签 wiki中的图表很有用。
我认为您应该通过您的业务简化这一点。这意味着当时钟倒转时，您可以通过将旧记录推到警告或错误表中并将新记录放在相同的时间间隔来回退记录。
正如马特所建议的那样，无论如何，如果按当地时间运行，报道将无法讲述真实的故事。那么，为什么在报告中给出错误的数据。
或者按照马特的建议再次更改您的间隔记录。然后，您不应将时间间隔绑定到 local_id。而是使用间隔 30 分钟运行的 Interval_seq_id，根据您所在的地区，给定日期可能有 48 条记录 (1-48)、50 条记录 (1-50) 或 52 条 (1-52) 条记录。从技术上讲，这将消除您在 Local_Int_starttime 和 Time_interval_Endtime 上的重复问题，它不再依赖或与时间间隔联系在一起。
不过，这会将问题转移到您的报告/查询工具上，以解决他们现在希望如何在本地时间重复的图表中显示时间。特别是，如果您想根据本地时间和仪表读数进行一些分析。但是，通过这种方式，数据库设计现在通过 Interval_Seq_id 区分记录，而不是使用时间间隔。
C# 这里有一个关于夏令时问题的类似主题。
答案深入到有关夏令时的详细信息中。我相信问题有点相似。