It happened this week while trying to figure out why Postgresql had a different behavior on apparently completely similar platforms. I'm born April 1st, let's say I want to save my birthday in a table, I'd go with the following SQL statement :
INSERT INTO birthdays (date) VALUES ('01-04-1981');

As I'm french, each time I deal with dates, I tend to verify that they were understood correctly. Indeed, the above date format was french ('dd-mm-YYYY') but postgresql could have interpreted as a US date format ('mm-dd-YYY'). So let's check with the following statement:
SELECT date_part('month',date) FROM birthdays;

Here comes the problem. On 2 different machines with (apparently) the same setup, this statement would return 2 different results. One would return '04' (correct) and the other one would return '01' (wrong).

I took me a while to find out that postgresql had datestyle option (in postgresql.conf) which defines the rule to interpret ambiguous date input values.

So if datestyle is set to 'iso, dmy', it means dates will be interpreted as 'date-month-year' and if it is set to 'iso-mdy', dates will be interpreted as 'month-date-year'. It is that simple... once you found it

Some of you noticed that I'm a little bit less reactive these times on savemyconf, that's true and it's because I accepted working as a CTO on another cool project. It means that most of my time in august and september is dedicated to Freelance Business Club, a social network for freelances in IT that has a lot of potential. They are currently in beta and my role is basically to technically turn this beta into a v1.0 version, a very good experience! For info, the new version will be released in end october...

And here's my new business card:

Don't you find it pretty ?

Obviously, working for Freelance Business Club slows me down a little on savemyconf, but development on savemyconf goes on! More about that soon...