When dateformat is changed to 'yyyy-mm-dd', the problem disappears.

I verified previous versions of limesurvey:
= v1.85+ build 7593 = Corrupts data with format 'dd-mm-yyyy'. Ok using 'yyyy-mm-dd'. So, it already had this problem in v1.85+.
= v1.71+ build 5535 = Ok. It is using format 'YYYY-MM-DD'; this cannot be changed.

So my suggestion is that the problem was introduced between v1.71+ build 5535 and v1.85+ build 7593.

I also checked other formats in v1.90+ build 9046.
dd.mm.yyyy : corrupts data
dd-mm-yyyy : corrupts data
dd/mm/yyyy : corrupts data
yyyy.mm.dd : works okay
yyyy-mm-dd : works okay
yyyy/mm/dd : works okay
d.m.yyyy : corrupts date

12.8.2010 becomes 20.12.2007
12.9.2010 becomes 20.12.2008
1.1.2010 becomes 20.9.2012
2.1.2010 becomes 20.9.2012
9.1.2010 becomes 20.9.2012
10.1.2010 becomes 20.12.2000
11.1.2010 becomes 20.12.2000
19.1.2010 becomes 20.12.2000
20.1.2010 becomes 20.12.2000
31.1.2010 becomes 20.12.2000
1.2.2010 becomes 20.9.2012
10.2.2010 becomes 20.12.2001
1.3.2010 becomes 20.9.2012
10.3.2010 becomes 20.12.2002
31.1.2010 becomes 20.12.2000

20.12.2007 becomes 20.7.2012
20.7.2012 becomes 20.2.2007
20.2.2007 becomes 20.7.2002
20.7.2002 becomes 20.2.2007

mm-dd-yyyy : corrupts data; 08-12-2010 becomes 07-31-2003
mm.dd.yyyy : corrupts data; 08.12.2010 becomes 07.31.2009
mm-dd-yyyy : corrupts data; 08-12-2010 now becomes 07-31-2009 ???

There is a second entry mm-dd-yyyy in the survey settings:
yyyy-mm-dd : works okay

thank you for the great analysis - we will have a look asap

Another question: Did you test on an inactive survey only? Is there a difference to a normal active survey?

I cannot reproduce the problem. >Works fine here on active and inactive surveys.
Can you provide a tiny sample survey please?

I tested on active surveys only.

For active survey: I see in the database the correct data. So, the data is not corrupted during the <Next> operation, but during the <Previous> operation.

I now also tested on an inactive survey and have the same result. Uuuh... cached in the SESSION variables? Can I check that?

As said, I can't reproduce here - I will need a sample survey. Maybe you did not properly update all your LimeSurvey files? Also try clearing your browser cache.
I just tried on our demo installation and it works fine there, too.

I created a new tiny survey and it did not reproduce. Clearing the browser cache did not solve the issue either.

So I will try what an apache restart does (server side cache?)

Clearing cache, restarting apache solves the data corruption in the tiny test survey, but not in the large (older) survey.

I will compary the definitions of the two surveys via phpMyAdmin...

Yes, or make a copy of the survey where the corruption occurs and trim it down until the bug goes away - maybe it is another question influencing this or a certain configuration.

I am getting crazy...
I changes the new tiny survey to look like the old large survey (all the survey detailed settings) and now run into the situation:

Using the tiny survey:
<Previous> -> <Next> keeps the proper date.
<Next> -> <Previous> currupts the date.

So, what am I missing?

"<Previous> -> <Next> keeps the proper date.
<Next> -> <Previous> currupts the date."

I am not sure what that means, do you click first previous, then next? Why don't you attach the survey and add specfic instructions how to reproduce.

See uploaded tiny test survey.
I stripped all confidential data, so it only includes the test survey.
I also removed the users table.

To produce.
Do survey ==> you see the opening screen.
Press <Next> ==> you see the two questions on group 1.
Question 1: Fill in today's date.
Question 2: Fill in some blabla.
Press <Previous> ==> you see the opening screen again.
Press <Next> ==> you see the two questions on group 1. The date is still today's.
Now press <Next> ==> you progress to group 2 (for the first time).
Now press <Previous> ==> you go back to group 1 with two questions. However, the date for question 1 is now corrupted.
Indeed: first <Previous>

Would it be possible check if lime-calendar.js is still proper?

The java script looks like it has a fixed date format, but I cannot see if this is related with my problem.

Fixed in rev 9063

Thank you - attached fixed file.

I don't know why the saved.php fixed the issue, but it did. It is confirmed that date isn't corrupted anymore.

Still wondering why adding '&& postedfileds' did the trick... and why lime-calendar.js wasn't involved.

Anyway, thanks Carsten.