Bug #8428
closed
Date#to_time yields incorrect value for Julian dates
Description
=begin
Date instances with Julian day values that precede the calendar reform start day (i.e. #julian? == true), return Time objects which do not correspond to the chronological Julian day which the Date instances represent.
d = Date.new(1582, 10, 15)
d.gregorian? # => true
d = d.jd # => 2299161
d.to_time.to_date.jd # => 2299161 (OK)
d = Date.new(1582, 10, 4)
d.gregorian? # => false
d = d.jd # => 2299160
d.to_time.to_date.jd # => 2299150 (!)
An equivalent Date object using a fixed Gregorian calendar does not exhibit the same behavior:
d = Date.new(1582, 10, 14, Date::GREGORIAN)
d == Date.new(1582, 10, 4) # => true
d = d.jd # => 2299160
d.to_time.to_date.jd # => 2299160 (OK)
Since the documentation for Date#to_time is not detailed about the expected behavior of Date#to_time ("returns a Time object which denotes self"), and since no rubyspec has been defined for this method yet, I realize that it is contentious to describe this behavior as a bug, so I'd like to put a few arguments forward that the current behavior is not correct or desirable.
(1) Since 1.9, Time#to_date always uses the Gregorian year, month and day indicated by a Time instance to construct a Date instance. This is a correction from Ruby 1.8's private Time#to_date, which used the calendar representation of the date according to the default reform day.
(2) The value of a Time instance is an instant defined as an offset from the Unix epoch. The instant falls within a particular chronological Julian day beginning at UTC-offset midnight. Date#to_time should respect the relationship between the chronological Julian day value of the Date instance and the Unix epoch offset value of the Time instance: If the value of the Time instance doesn't fall within the same chronological Julian day as is represented by the Date instance, the conversion is incorrect.
(3) Although an instance of Time is capable of representing the beginning of any chronological Julian day, it is not capable or representing a date in the Julian calendar. Since an instance of Time masquerading as a Julian date such as the current result of (({Date.new(1582, 10, 4).to_time})) actually represents a different value, its value and any calculations based on its value are likely to mislead, as are comparisons with other instances of Time.
The following patch to (({ext/date/date_core.c})) would make Date#to_time work uniformly for Gregorian and Julian dates:
@@ -8604,12 +8604,21 @@ time_to_datetime(VALUE self)
static VALUE
date_to_time(VALUE self)
{
- get_d1(self);
- return f_local3(rb_cTime,
-
m_real_year(dat), -
INT2FIX(m_mon(dat)), -
INT2FIX(m_mday(dat)));
- get_d1a(self);
- if (m_julian_p(adat)) {
-
VALUE tmp = d_lite_gregorian(self); -
get_d1b(tmp); -
return f_local3(rb_cTime, -
m_real_year(bdat), -
INT2FIX(m_mon(bdat)), -
INT2FIX(m_mday(bdat))); - }
- else {
-
return f_local3(rb_cTime, -
m_real_year(adat), -
INT2FIX(m_mon(adat)), -
INT2FIX(m_mday(adat))); - }
}
If this proposal is too contentious for a bug report, I would be glad to reintroduce it in a mailing list or in whatever forum is deemed more appropriate for discussing a change like this. Thank you for your consideration!
=end
Updated by