| Subject: | String comparison of two DateTime objects too accurate? |
DateTime currently uses (after a lot of scaffolding) utc_rd_values() to
perform a string comparison between two DateTime objects. This takes
into account nanoseconds. Since the default string form does not show
nanoseconds it leads to the strange case where two apparently equal
strings are not equal.
For example:
use DateTime;
my $foo = DateTime->new(year => 2010, nanosecond => 123);
my $bar = DateTime->new(year => 2010, nanosecond => 456);
print $foo eq $bar ? "Equal" : "Not equal";
print $foo;
print $bar;'
__END__
Not equal
2010-01-01T00:00:00
2010-01-01T00:00:00
I'm not sure what's to be done with this, but it is difficult to debug.
One choice is to leave "eq" as a string comparison operator and just
compare DateTime objects as strings rather than as dates. This removes
the surprise, but it also removes a possibly valuable increased accuracy
and its probably backwards compatible.
Another is to compare using lower accuracy, one more in line with what's
displayed, such as utc_rd_as_seconds. This will bring the results in
line with the level of accuracy shown in the default string
representation while retaining cross time zone equality. OTOH people
may change the string format to one that includes nanoseconds, and its
probably backwards incompatible.
Another is to throw a warning when a string comparison fails because of
a nanosecond difference. OTOH this may get noisy.