Created attachment 60781 [details] sample document Steps how to reproduce with parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 52348aa]" (tinderbox: Win-x86@6-fast, pull time 2012-04-27 21:25:23): open attached sample document, do inputs as requested in front of the input cells. In column C you see results of same proceeding with an older "English only" Master version, "15." will be recognized as the 15th day of the month due to German locale setting. Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 3b32204-7f92fce-2ba0a9f)]" (2011-09-03) recognizes and converts without problem (sometimes resulting date is unexpected, but that is because of Locale related conversion differences that have to be respected): 12/04/15 12/15/04 2012-04-15 works also in 3.6 Master 12-04-15 works also in 3.6 Master 15. April works also in 3.6 Master 15.
Already broken in "LOdev 3.6.0alpha0+ English UI/Locale [Build ID: 9518535-d09cf17-8a74106-c695ecd-16afab
Additionally visible wiht MinGW Master Build 2012-04-26, wo I think I reproduced problem with enough different builds for NEW. @Kohei: Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug BTW: is it still ok that I always "preassign" CALC Bugs to you or would you prefer some in turn proceeding kohei - markus - erack?
I get Sunday, January 14, 1900 on 3.5.1.2 (Linux).
Created attachment 60911 [details] Bad inverted commas Also, I believe, you inverted commas look a lot different in my case. This's the snapshot of the same calc document.
@dE: Note that Rainer works in a German locale, in other locales you get different results.
@Rainer: number formatter / scanner bugs are usually my area. However, the changes you noticed are desired behavior, the "accept almost everything as date in every locale" behavior is gone as it drove people nuts. Specifically the "any digit followed by a dot and maybe another digit" was insane as people tried to enter lists such as 1. 2. and ended up with dates instead, we had many complaints about that. Also, in a German locale the '.' dot is now required as date separator, '/' does not work anymore and '-' only if the input denotes an ISO 8601 date. Incomplete dates are only accepted as D.M. (note trailing dot, so 15.5 is still not a date). See also http://wiki.documentfoundation.org/ReleaseNotes/3.6#Localization "Implemented locale dependent date acceptance patterns"