DBI doesn't load the right DateTime.

Consider the following script: test.rb
=============================================================================
#!/usr/bin/ruby -w
# vim: ts=2 sw=2 et
require 'date'
require 'rubygems'
require 'dbi'

DSN = 'DBI:Pg:gpsgate'
USER = 'gpsgate'

DBI.connect(DSN, USER) {|db|
  a = DateTime.parse('2009-08-30T11:22:07+00:00')
  st = db.execute "SELECT timestamp with time zone '2009-08-30 18:22:07+07'"
  b = st.fetch[0]
  c = DateTime.strptime(b.to_s)
  puts "a == b : #{a} == #{b} : #{a == b}"
  puts "a == c : #{a} == #{c} : #{a == c}"
  puts "a = #{a.inspect}"
  puts "b = #{b.inspect}"
  puts "c = #{c.inspect}"
}
=============================================================================

This the output on my machine:
=======================================================================
$ ./test.rb
a == b : 2009-08-30T11:22:07+00:00 == 2009-08-30T18:22:07+07:00 : false
a == c : 2009-08-30T11:22:07+00:00 == 2009-08-30T18:22:07+07:00 : true
a = #<DateTime: 212118391327/86400,0,2299161>
b = #<DateTime: 2455074.2653588,0.291666666666667,2299161>
c = #<DateTime: 212118391327/86400,7/24,2299161>

$ ruby -rubygems -e 'require "dbd/Pg";puts DBI::DBD::Pg::VERSION'
0.3.8

$ ruby -rubygems -e 'require "dbi";puts DBI::VERSION'
0.4.3

$ ruby -v
ruby 1.8.6 (2008-08-11 patchlevel 287) [i486-linux]
Ruby Enterprise Edition 20090610

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu 8.04.3 LTS"
=======================================================================

My limited investigation leads me to DBI::Type::Timestamp
but my fix broke the others.

Date: 2009-09-28 01:58
Sender: Erik Hollensbe

I actually just (like, a few minutes ago) fixed this for all
known cases (and your new ones) in our test suite.

This fix is published to github in the 'development' branch,
but github's website seems to be down at the moment.

http://github.com/erikh/ruby-dbi for more information when the
site comes back up.

It will likely be released this week with a few more fixes.

Date: 2009-09-28 01:32
Sender: Zakaria Haris

Thanks you Erik for your speedy response.

For the moment I workaround this bug by doing
DateTime.strptime(time.to_s) on affected DateTime value.

Because my workaround is good enough, I'll wait for proper
release then.

Date: 2009-09-26 16:44
Sender: Erik Hollensbe

Hello Zakaria,

First, let me say it's refreshing to see such a detailed bug
report. :)

Second, I've figured out the problem but don't quite have a fix
yet (and we probably won't release today), but this may help
you in your comparisons for the time being.

What DBI does when it parses the DateTime is build it out manually;
this was merged in a few months back and is significantly (by
several orders of magnitude) faster than using parse.

However, there is an error in our parsing routines, one that's
rather benign unless this use case comes up.

In your example, a and c have offsets (DateTime#offset) that
are represented as rational numbers through class Rational. b,
our calculated version, builds its offset as Float.

The problem here is one of precision; you can see this by running
"p a.offset.to_f; p b.offset; p c.offset.to_f". The
Float representations are exactly the same, but you will see
that these numbers are meant to have infinite precision which
Rational accounts for, but Float obviously does not. DateTime#equal?
(or more likely, Rational#equal?) cares about this.

I will get to fixing this today and will comment again if I have
any success; you will be able to retrieve it from the development
branch on github. In the meantime however, you may just want
to compare the offset's float representation manually, which
should be close enough for almost any sane application. :)