以UTC格式保存日期时间有时不准确

Question

通常,处理日期时的最佳做法是将它们存储在UTC中并转换回用户在应用程序层中所期望的任何内容.

这不一定适用于将来的日期,特别是在日期/时间特定于用户时区的情况下.基于当地时间的时间表需要存储当地时间.

在我的情况下,有一个属性,它是一个包含未来事件的START_TIME时间戳,相比于其他一切现在或过去(包括created_at和updated_at时间戳).

为什么

该特定字段是用户选择时间的未来事件的时间戳.

对于未来的事件,似乎最好的做法是不存储UTC.

开发人员可以保存用户期望我们保存的内容:停机时间,而不是将时间与时区一起保存.

当用户选择上午10点时,即使由于夏令时用户与UTC的偏移在创建和事件日期之间发生变化,它也需要保持上午10点.

因此,在2016年6月,如果用户在悉尼午夜2017年1月1日创建活动,则该时间戳将作为数据库存储在数据库中2017-01-01 00:00.创建时的偏移量为+10:00,但在事件发生时,它是+11:00 ..除非政府决定在此期间改变它.

同样明智的,我希望我在2016年1月1日午夜在布里斯班创建一个单独的活动,也可以存储为2017-01-01 00:00.我存储时区,即存储Australia/Brisbane在单独的字段中.

在Rails中执行此操作的最佳实践方法是什么？

我尝试了很多选择但没有成功:

1.跳过转换

问题,这只会在读取时跳过转换,而不是写入.

self.skip_time_zone_conversion_for_attributes = [:start_time]

2.更改要使用的整个应用程序配置 config.default_timestamp :local

为此,我设置:

配置/ application.rb中

config.active_record.default_timezone = :local
config.time_zone = 'UTC'

应用程序/模型/ event.rb

...
self.skip_time_zone_conversion_for_attributes = [:start_time]
before_save :set_timezone_to_location
after_save :set_timezone_to_default

def set_timezone_to_location
  Time.zone = location.timezone
end

def set_timezone_to_default
  Time.zone = 'UTC'
end
...

坦率地说,我不确定这是做什么的......但不是我想要的.

我认为它的存在是因为我的布里斯班事件被存储为,2017-01-01 00:00但是当我为悉尼创建一个新事件时,它被存储为2017-01-01 01:00即使它在视图中正确显示为午夜.

既然如此,我担心悉尼事件仍然存在同样的问题,我正试图避免.

3.覆盖模型的getter和setter以存储为整数

我试图将事件start_time存储为数据库中的整数.

我尝试通过猴子修补Time类并添加before_validates回调来进行转换.

配置/初始化/ time.rb

class Time
  def time_to_i
    self.strftime('%Y%m%d%H%M').to_i
  end
end

应用程序/模型/ event.rb

before_validation :change_start_time_to_integer
def change_start_time_to_integer
  start_time = start_time.to_time if start_time.is_a? String
  start_time = start_time.time_to_i
end

# read value from DB
# TODO: this freaks out with an error currently
def start_time
  #take integer YYYYMMDDHHMM and convert it to timestamp
  st = self[:start_time]
  Time.new(
    st / 100000000,
    st / 1000000 % 100,
    st / 10000 % 100,
    st / 100 % 100,
    st % 100,
    0,
    offset(true)
  )
end

理想解决方案

我想能够存储在数据库中的数据类型自然的时间戳所以查询不会得到我的控制器凌乱,但我无法弄清楚如何存储"挂钟时间",不转换.

第二好,如果必须,我会选择整数选项.

别人怎么处理这个？我错过了什么？特别是上面的"整数转换"选项,我使事情变得比他们需要的复杂得多.

Answer 1

我建议您仍然使用第一个选项,但有一点点黑客:实质上,您可以关闭所需属性的时区转换,并使用自定义setter来克服属性写入期间的转换.

该技巧将时间节省为假的UTC时间.虽然从技术上讲它具有UTC区域(因为所有时间都以UTC格式保存在db中),但根据定义,它应被解释为本地时间,而不管当前时区.

class Model < ActiveRecord::Base
  self.skip_time_zone_conversion_for_attributes = [:start_time]

  def start_time=(time)
    write_attribute(:start_time, time ? time + time.utc_offset : nil)
  end
end

我们在rails控制台中测试一下:

$ rails c
>> future_time = Time.local(2020,03,30,11,55,00)
=> 2020-03-30 11:55:00 +0200

>> Model.create(start_time: future_time)
D, [2016-03-15T00:01:09.112887 #28379] DEBUG -- :    (0.1ms)  BEGIN
D, [2016-03-15T00:01:09.114785 #28379] DEBUG -- :   SQL (1.4ms)  INSERT INTO `models` (`start_time`) VALUES ('2020-03-30 11:55:00')
D, [2016-03-15T00:01:09.117749 #28379] DEBUG -- :    (2.7ms)  COMMIT
=> #<Model id: 6, start_time: "2020-03-30 13:55:00">

请注意,Rails将时间保存为"假"UTC区域中的11:55.

另请注意,返回的对象中的时间create是错误的,因为在这种情况下区域是从"UTC"转换的.您必须使用它并在设置start_time属性后每次重新加载对象,以便可以进行区域转换跳过:

>> m = Model.create(start_time: future_time).reload
D, [2016-03-15T00:08:54.129926 #28589] DEBUG -- :    (0.2ms)  BEGIN
D, [2016-03-15T00:08:54.131189 #28589] DEBUG -- :   SQL (0.7ms)  INSERT INTO `models` (`start_time`) VALUES ('2020-03-30 11:55:00')
D, [2016-03-15T00:08:54.134002 #28589] DEBUG -- :    (2.5ms)  COMMIT
D, [2016-03-15T00:08:54.141720 #28589] DEBUG -- :   Model Load (0.3ms)  SELECT  `models`.* FROM `models` WHERE `models`.`id` = 10 LIMIT 1
=> #<Model id: 10, start_time: "2020-03-30 11:55:00">

>> m.start_time
=> 2020-03-30 11:55:00 UTC

加载对象后,该start_time属性是正确的,无论实际时区如何,都可以手动解释为本地时间.

我真的不明白为什么Rails的行为方式与skip_time_zone_conversion_for_attributes配置选项有关...

更新:添加阅读器

我们还可以添加一个阅读器,以便我们在当地时间自动解释保存的"假"UTC时间,而不会因时区变化而改变时间:

class Model < ActiveRecord::Base
  # interprets time stored in UTC as local time without shifting time
  # due to time zone change
  def start_time
    t = read_attribute(:start_time)
    t ? Time.local(t.year, t.month, t.day, t.hour, t.min, t.sec) : nil
  end
end

在rails控制台中测试:

>> m = Model.create(start_time: future_time).reload
D, [2016-03-15T08:10:54.889871 #28589] DEBUG -- :    (0.1ms)  BEGIN
D, [2016-03-15T08:10:54.890848 #28589] DEBUG -- :   SQL (0.4ms)  INSERT INTO `models` (`start_time`) VALUES ('2020-03-30 11:55:00')
D, [2016-03-15T08:10:54.894413 #28589] DEBUG -- :    (3.1ms)  COMMIT
D, [2016-03-15T08:10:54.895531 #28589] DEBUG -- :   Model Load (0.3ms)  SELECT  `models`.* FROM `models` WHERE `models`.`id` = 12 LIMIT 1
=> #<Model id: 12, start_time: "2020-03-30 11:55:00">

>> m.start_time
=> 2020-03-30 11:55:00 +0200

即start_time在本地时间正确解释,即使它以相同的小时和分钟存储,但以UTC格式存储.