Tom Insam

Irritating 2038 Ruby / Rails behaviour

In a rails console:

>> ( + 30.years).class
=> Time
>> ( + 31.years).class
=> DateTime
>> ( + 30.years).to_s
=> "Sat Oct 17 17:27:11 +0100 2037"
>> ( + 31.years).to_s
=> "2038-10-17T17:27:13+01:00"

Time objects after about August 2028 can't be expressed internally as 'UNIX epoch (1st January 1970) plus N seconds' where N is a 32 bit integer. Once a Time object tries to express a date after this point, it gets silently converted to a DateTime object, which presumably uses a different internal representation. It also stringifies differently, has different methods, and is just generally annoying behaviour.

When you have dates in a MySQL database, and use ActiveRecord, DATETIME columns come out of the table as either a Time or a DateTime object depending on what the expressed date is. Lovely. This bug indicates that dates before 1970 behave similarly (they can't be expressed as unsigned epoch times either).

This is apparently desired behaviour.

Update: Apparently, DateTime objects are also much slower than Date objects.