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.
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@gmail.com> wrote: