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.<br>
<br>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.<div>
<br></div><div><div>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.</div>
<div><br></div><div>Best,</div><div>Leon<br><br><div class="gmail_quote">On Sun, Jun 3, 2012 at 11:30 AM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p>Thanks for the reference to November 18, 1883. That was an interesting read!</p>
<p>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.</p>
<p>I looked at the code a bit, it looks good to me.</p>
<div class="gmail_quote">On Jun 2, 2012 8:40 PM, "Leon Smith" <<a href="mailto:leon.p.smith@gmail.com" target="_blank">leon.p.smith@gmail.com</a>> wrote:<br type="attribution"></div>
</blockquote></div><br></div></div>