应用程序配置的时区不是UTC。它还设置
config.timezone = 'Bogota'
config.active_record.default_timezone = :local`这样做的动机是让系统时间戳与应用程序的主要时区一起设置。
然而，应用程序收集datetime类型的数据以及它发生的时区。记录的参数为：
"event"=>{"name_last"=>"tz event", "date(3i)"=>"1", "date(2i)"=>"1", "date(1i)"=>"1987", "date(4i)"=>"01", "date(5i)"=>"01", "tz"=>"Hawaii"数据库具有不同的属性：一个是约会时间
t.timestamptz "date"
t.string "tz"我们的目标是让用户能够查看tz中的timestamptz属性，以及UTC中的。
问题是，输入被处理，就好像它是在应用程序的配置时区。* 删除时区配置并全面使用UTC是否更明智？*
如何处理这些参数以正确地保存postgresql中具有输入时区的记录-考虑潜在的夏令时-然后使用两种数据表示形式（UTC和事件的时区）查看？
1条答案
按热度按时间n3schb8v1#
如何在数据库中存储时间点应取决于它们描述的事件在本质上是否与时区相关。这会对将来的事件产生影响，因为时区的定义可能会在事件写入数据库之后但在事件到达之前发生更改。
下面是一个与时区相关的事件的示例：
假设下一次大选的投票站在我所在时区的2025-09- 21 T08：00：00+02：00开放。但如果我国在此之前取消夏令时，他们将在2025-09- 21 T08：00：00+01：00开放，而没有明确的重新安排。换句话说：UTC时间会更改（从2025-09- 21 T06：00：00 Z更改为2025-09- 21 T07：00：00 Z），但本地时间不变。此类事件应与其本地时间（2025-09- 21 T08：00：00）及其时区一起存储。
与时区无关的事件的一个例子是小行星最接近地球的时刻。
将时区相关的事件转换为其他时区是复杂的，然而，如果可以证明的话（例如，因为它们都位于过去），那么将事件存储在UTC中会更简单。
(Note然而，时区数据库有时甚至会更新几年前的数据，例如，在某人发现某个地区在1835年至1839年之间引入了夏令时之后。