[database-devel] UTCTime and Timestamp Without Time Zone

Leon Smith leon.p.smith at gmail.com
Mon Jun 4 15:02:56 CEST 2012

Well, I played around with it a little more,  and discovered that the  1883
Nov 18 behavior is specific to my local time zone.   I think the moral of
the story is that time is messy and complicated,  and that I should
probably extend the timezone parser at least a little bit.    Unfortunately
GHC's time package assumes that time zones are offset by an integer number
of minutes,  so handling the 3 minute and 58 second offset used in that
sample case is a bit trickier.   And given that I doubt most people will
care about timestamps before the 20th century,  I'll probably release
without dealing with this.

Then again,  an even better solution would be to get postgresql-simple to
the point it can send and receive binary values.    By default, PostgreSQL
8.4 and newer represents timestamps as 64-bit ints of microseconds before
or after 2000-01-01 00:00:00+00;  sending and receiving this format would
be a great deal faster,  and would isolate these types of corner cases to
Haskell alone,  instead of infecting the interface between PostgreSQL and

Unfortunately,  receiving results in binary is currently an all-or-nothing
proposition,  which certainly complicates the situation.    It is not so
easy to selectively receive some columns in binary and the rest in the
textual format.   You can explicitly cast/convert some columns to text,
 but then you also change the type OIDs that Haskell sees.   The most
convenient thing would be able to set a connection-specific variable that
controls which types are received in binary and which types are not;  but
to the best of my knowledge,  PostgreSQL has no such thing.


On Sun, Jun 3, 2012 at 11:30 AM, Michael Snoyman <michael at snoyman.com>wrote:

> Thanks for the reference to November 18, 1883. That was an interesting
> read!
> I agree with your analysis of the situation with types. If this results in
> the need for breaking changes to persistent-postgresql, so be it. I'd
> rather have correctness than false stability.
> I looked at the code a bit, it looks good to me.
> On Jun 2, 2012 8:40 PM, "Leon Smith" <leon.p.smith at gmail.com> wrote:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/database-devel/attachments/20120604/1575a653/attachment.htm>

More information about the database-devel mailing list