较新版本的 Ruby (2.0+) 在这两个类之间并没有真正的显着差异。由于历史原因,一些库会使用其中一种,但不一定需要关注新代码。选择一个以保持一致性可能是最好的,因此请尝试与您的库所期望的相结合。例如,ActiveRecord 更喜欢 DateTime。
在 Ruby 1.9 之前的版本和许多系统上,时间表示为一个 32 位有符号值,描述自 1970 年 1 月 1 日 UTC 以来的秒数,它是一个围绕 POSIX 标准 time_t
值的薄包装器,并且是有界的:
Time.at(0x7FFFFFFF)
# => Mon Jan 18 22:14:07 -0500 2038
Time.at(-0x7FFFFFFF)
# => Fri Dec 13 15:45:53 -0500 1901
较新版本的 Ruby 能够处理更大的值而不会产生错误。
DateTime 是一种基于日历的方法,其中单独存储年、月、日、小时、分钟和秒。这是一个 Ruby on Rails 构造,用作 SQL 标准 DATETIME 字段的包装器。这些包含任意日期,并且几乎可以表示任何时间点,因为表达式的范围通常非常大。
DateTime.new
# => Mon, 01 Jan -4712 00:00:00 +0000
所以令人放心的是,DateTime 可以处理来自亚里士多德的博客文章。
选择一个时,差异现在有些主观。从历史上看,DateTime 提供了更好的以日历方式操作它的选项,但其中许多方法也已移植到 Time 中,至少在 Rails 环境中是这样。
[编辑 2018 年 7 月]
以下所有内容在 Ruby 2.5.1 中仍然适用。从 reference documentation:
DateTime 不考虑任何闰秒,不跟踪任何夏令时规则。
之前在此线程中没有提到的是 DateTime
的少数优点之一:它知道日历改革,而 Time
不知道:
[...] Ruby 的 Time 类实现了一个预测的公历并且没有日历改革的概念 [...]。
参考文档最后建议在专门处理近乎过去、当前或未来的日期/时间时使用 Time
,并且仅在需要准确转换莎士比亚的生日等情况下使用 DateTime
:(强调添加)
那么什么时候应该在 Ruby 中使用 DateTime,什么时候应该使用 Time?几乎可以肯定,您会想要使用 Time,因为您的应用程序可能正在处理当前日期和时间。但是,如果您需要在历史背景下处理日期和时间,您将需要使用 DateTime [...]。如果您还必须处理时区,那么祝您好运 - 请记住,您可能会处理当地太阳时,因为直到 19 世纪铁路的引入才需要标准时间最终的时区。
[/编辑 2018 年 7 月]
从 ruby 2.0 开始,其他答案中的大部分信息都已过时。
特别是,Time
现在实际上是未绑定的。距离 Epoch 甚至可以多或少 63 位:
irb(main):001:0> RUBY_VERSION
=> "2.0.0"
irb(main):002:0> Time.at(2**62-1).utc # within Integer range
=> 146138514283-06-19 07:44:38 UTC
irb(main):003:0> Time.at(2**128).utc # outside of Integer range
=> 10783118943836478994022445751222-08-06 08:03:51 UTC
irb(main):004:0> Time.at(-2**128).utc # outside of Integer range
=> -10783118943836478994022445747283-05-28 15:55:44 UTC
使用较大值的唯一结果应该是性能,使用 Integer
时性能更好(与 Bignum
(值超出 Integer
范围)或 Rational
(跟踪纳秒时)相比):
从 Ruby 1.9.2 开始,Time 实现使用带符号的 63 位整数、Bignum 或 Rational。该整数是自 Epoch 以来的纳秒数,可以表示 1823-11-12 到 2116-02-20。当使用 Bignum 或 Rational 时(在 1823 之前,在 2116 之后,纳秒以下),Time 的工作速度与使用整数时一样慢。 (http://www.ruby-doc.org/core-2.1.0/Time.html)
换言之,据我了解,DateTime
不再涵盖比 Time
更广泛的潜在价值。
此外,可能应该注意两个先前未提及的 DateTime
限制:
DateTime 不考虑任何闰秒,不跟踪任何夏令时规则。 (http://www.ruby-doc.org/stdlib-2.1.0/libdoc/date/rdoc/Date.html#class-Date-label-DateTime)
首先,DateTime
没有闰秒的概念:
irb(main):001:0> RUBY_VERSION
=> "2.0.0"
irb(main):002:0> require "date"
=> true
irb(main):003:0> t = Time.new(2012,6,30,23,59,60,0)
=> 2012-06-30 23:59:60 +0000
irb(main):004:0> dt = t.to_datetime; dt.to_s
=> "2012-06-30T23:59:59+00:00"
irb(main):005:0> t == dt.to_time
=> false
irb(main):006:0> t.to_i
=> 1341100824
irb(main):007:0> dt.to_time.to_i
=> 1341100823
要使上述示例与 Time
一起使用,操作系统需要支持闰秒,并且需要正确设置时区信息,例如通过 TZ=right/UTC irb
(在许多 Unix 系统上)。
其次,DateTime
对时区的了解非常有限,尤其是没有夏令时的概念。它几乎将时区处理为简单的 UTC + X 偏移量:
irb(main):001:0> RUBY_VERSION
=> "2.0.0"
irb(main):002:0> require "date"
=> true
irb(main):003:0> t = Time.local(2012,7,1)
=> 2012-07-01 00:00:00 +0200
irb(main):004:0> t.zone
=> "CEST"
irb(main):005:0> t.dst?
=> true
irb(main):006:0> dt = t.to_datetime; dt.to_s
=> "2012-07-01T00:00:00+02:00"
irb(main):007:0> dt.zone
=> "+02:00"
irb(main):008:0> dt.dst?
NoMethodError: undefined method `dst?' for #<DateTime:0x007f34ea6c3cb8>
当时间以 DST 形式输入然后转换为非 DST 时区而不跟踪 DateTime
本身之外的正确偏移量时,这可能会导致麻烦(许多操作系统实际上可能已经为您处理了这一点)。
总的来说,我会说现在 Time
是大多数应用程序的更好选择。
还要注意加法的一个重要区别:当您将数字添加到 Time 对象时,它以秒计,但当您将数字添加到 DateTime 时,它以天计。
Time
也没有闰秒的概念,因此它与 DateTime
没有什么不同。我不知道您在哪里运行您的示例,但我在不同的 Ruby 版本(从 2.0 到 2.7)中尝试了 Time.new(2012,6,30,23,59,60,0)
,但总是得到 2012-07-01 00:00:00 +0000
。
Time
是否支持闰秒取决于您的操作系统和时区配置。例如:TZ=right/UTC ruby -e 'p Time.new(2012,6,30,23,59,60,0)'
=> 2012-06-30 23:59:60 +0000
而 TZ=UTC ruby -e 'p Time.new(2012,6,30,23,59,60,0)'
=> 2012-07-01 00:00:00 +0000
。
我认为“有什么区别”的答案是 Ruby 标准库中这个问题的不幸常见答案之一:这两个类/库是由不同的人在不同的时间以不同的方式创建的。与精心策划的 Java 之类的开发相比,这是 Ruby 发展的社区性质的不幸后果之一。开发人员想要新功能,但不想踩到现有的 API,所以他们只是创建了一个新类——对于最终用户来说,两者并没有明显的理由存在。
这对于一般的软件库来说是正确的:通常一些代码或 API 的原因是它被证明是历史的而不是逻辑的。
诱惑是从 DateTime 开始,因为它看起来更通用。日期...和时间,对吗?错误的。 Time 也可以更好地处理日期,实际上可以解析 DateTime 无法解析的时区。它的性能也更好。
我最终在任何地方都使用了时间。
不过为了安全起见,我倾向于允许将 DateTime 参数传递到我的 Timey API 中,或者进行转换。另外,如果我知道两者都有我感兴趣的方法,我也接受,就像我写的将时间转换为 XML 的方法(用于 XMLTV 文件)
# Will take a date time as a string or as a Time or DateTime object and
# format it appropriately for xmtlv.
# For example, the 22nd of August, 2006 at 20 past midnight in the British Summertime
# timezone (i.e. GMT plus one hour for DST) gives: "20060822002000 +0100"
def self.format_date_time(date_time)
if (date_time.respond_to?(:rfc822)) then
return format_time(date_time)
else
time = Time.parse(date_time.to_s)
return format_time(time)
end
end
# Note must use a Time, not a String, nor a DateTime, nor Date.
# see format_date_time for the more general version
def self.format_time(time)
# The timezone feature of DateTime doesn't work with parsed times for some reason
# and the timezone of Time is verbose like "GMT Daylight Saving Time", so the only
# way I've discovered of getting the timezone in the form "+0100" is to use
# Time.rfc822 and look at the last five chars
return "#{time.strftime( '%Y%m%d%H%M%S' )} #{time.rfc822[-5..-1]}"
end
Time.new(2011, 11, 1, 10, 30)
产生 2011-11-01 10:30:00 +0700
而 DateTime.new(2011, 11, 1, 10, 30)
产生 Tue, 01 Nov 2011 10:30:00 +0000
。
假设您使用 ActiveSupport 扩展,我发现使用 DateTime 更容易解析和计算不同时区一天的开始/结束之类的事情。
在我的情况下,我需要根据我作为字符串收到的用户本地时间计算用户时区(任意)的一天结束,例如“2012-10-10 10:10 +0300”
使用 DateTime 它就像
irb(main):034:0> DateTime.parse('2012-10-10 10:10 +0300').end_of_day
=> Wed, 10 Oct 2012 23:59:59 +0300
# it preserved the timezone +0300
现在让我们用同样的方式尝试一下 Time:
irb(main):035:0> Time.parse('2012-10-10 10:10 +0300').end_of_day
=> 2012-10-10 23:59:59 +0000
# the timezone got changed to the server's default UTC (+0000),
# which is not what we want to see here.
实际上,Time 在解析之前需要知道时区(还要注意它是 Time.zone.parse
,而不是 Time.parse
):
irb(main):044:0> Time.zone = 'EET'
=> "EET"
irb(main):045:0> Time.zone.parse('2012-10-10 10:10 +0300').end_of_day
=> Wed, 10 Oct 2012 23:59:59 EEST +03:00
因此,在这种情况下,使用 DateTime 肯定更容易。
DateTime.parse('2014-03-30 01:00:00 +0100').end_of_day
产生 Sun, 30 Mar 2014 23:59:59 +0100
,但 Time.zone = 'CET'; Time.zone.parse('2014-03-30 01:00:00').end_of_day
产生 Sun, 30 Mar 2014 23:59:59 CEST +02:00
(CET=+01:00,CEST=+02:00 - 注意偏移量已更改)。但要做到这一点,您需要有关用户时区的更多信息(不仅是偏移量,还有是否使用节省时间)。
Time.zone.parse
非常很有用 - 它迫使您考虑应该使用哪个区域。有时, Time.find_zone 效果更好。
DateTime
确实解析了您给它的偏移量,即 +0100。您没有给 Time
一个偏移量,而是一个时区(“CET”没有描述偏移量,它是一个时区的名称)。时区全年可以有不同的偏移量,但偏移量就是偏移量,并且始终相同。
考虑他们如何使用自定义实例化以不同方式处理时区:
irb(main):001:0> Time.new(2016,9,1)
=> 2016-09-01 00:00:00 -0400
irb(main):002:0> DateTime.new(2016,9,1)
=> Thu, 01 Sep 2016 00:00:00 +0000
irb(main):003:0> Time.new(2016,9,1).to_i
=> 1472702400
irb(main):004:0> DateTime.new(2016,9,1).to_i
=> 1472688000
在创建时间范围等时,这可能会很棘手。
除了 the answer of Niels Ganser,您还可以考虑以下参数:
请注意,The Ruby Style Guide 非常清楚地表明了对此的立场:
没有 DateTime 除非您需要考虑历史日历改革,否则不要使用 DateTime - 如果您这样做,请明确指定 start 参数以明确说明您的意图。 # bad - 使用 DateTime 作为当前时间 DateTime.now # good - 使用 Time 作为当前时间 Time.now # bad - 使用 DateTime 作为现代日期 DateTime.iso8601('2016-06-29') # good - 使用 Date 作为现代日期Date.iso8601('2016-06-29') # 好 - 使用带有 start 参数的 DateTime 作为历史日期 DateTime.iso8601('1751-04-23', Date::ENGLAND)
似乎在某些情况下行为非常不同:
Time.parse("Ends from 28 Jun 2018 12:00 BST").utc.to_s
“2018-06-28 09:00:00 UTC”
Date.parse("Ends from 28 Jun 2018 12:00 BST").to_time.utc.to_s
“2018 年 6 月 27 日 21:00:00 UTC”
DateTime.parse("Ends from 28 Jun 2018 12:00 BST").to_time.utc.to_s
“2018 年 6 月 28 日 11:00:00 UTC”
Date
(不出所料)仅解析日期,当 Date
转换为 Time
时,它始终使用本地时区的午夜作为时间。 Time
和 TimeDate
之间的区别在于 Time
不理解 BST,这令人惊讶,因为 Time
通常更正确地处理时区(例如,关于夏令时)。所以在这种情况下,只有 DateTime
可以正确解析整个字符串。