[database-devel] UTCTime and Timestamp Without Time Zone
greg at gregweber.info
Mon Jun 4 16:23:33 CEST 2012
There is some work under way for an improved time zone library that
you might be interested in:
On Mon, Jun 4, 2012 at 6:02 AM, Leon Smith <leon.p.smith at gmail.com> wrote:
> 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 Haskell.
> 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>
>> Thanks for the reference to November 18, 1883. That was an interesting
>> 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:
> database-devel mailing list
> database-devel at haskell.org
More information about the database-devel