Re: [database-devel] UTCTime and Timestamp Without Time Zone

There is some work under way for an improved time zone library that you might be interested in: https://github.com/alphaHeavy/time-cube On Mon, Jun 4, 2012 at 6:02 AM, Leon Smith 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.

Best, Leon

On Sun, Jun 3, 2012 at 11:30 AM, Michael Snoyman 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" wrote:

_______________________________________________ database-devel mailing list database-devel@haskell.org http://www.haskell.org/mailman/listinfo/database-devel