Created attachment 64822 [details] Spreadsheet with wrong results If i tyype a date before July 26, 1790 one day is subtracted. E.g. If I type 23.7.1790 the date shown is 22.07.1790 24.7.1790 --> 23.07.1790 25.7.1790 --> 24.07.1790 26.6.1790 --> 26.07.1790 27.6.1790 --> 27.07.1790 Date 25.07.1790 is never shown The attached spreadsheet shows this problem. Column B is created with autofill, in Column c the same dates have been typed in manually. This problem does not seem to occur with LO 3.5.3
[Reproducible] with parallel installation of Master "LOdev " 3.7.0.0.alpha0+ - WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 66e4540]" (tinderbox:Win-x86@6, pull time 2012-07-26 02:09:47): Input "7/24/1790" into a new empty spreadsheet has result "07/23/1790" [Reproducible] with Server Installation of "LibreOffice 3.6.0.2 rc German UI/Locale [Build-ID: 815c576] on German WIN7 Home Premium (64bit) exactly as per original report DUP of or related to "Bug 44367 - EDITING: Wrong display when inputting/viewing dates before 1.1.1900"? "Bug 44286 - [EDITING] Calc decreases one day of a date typed (Brazilian-portuguese locale and timezone)"?
Already broken with Server installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: a502549]" (tinderbox: Win-x86@6-fast, pull time 2012-05-31 07:33:55) Was ok with - 3.6.0.0.alpha+ 2012-04-26 MinGW - Server installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 475d0c5-829fc92-39746e8-206648e-fefd87]" (2012-02-14) @Eike: You just art rather active in date issues ...
Same problem occurs with the DATUM function. =DATUM(1790;7;24) gives 23.07.1790 Regards
After reading bug 105864 (old OpenOffice) I did some tests. I am using Central European Timezon (UTC+1, DLT (summer time) enabled). The error occurs. If I change the timezone (e.g. UTC-5), the error does not occur. If I change the timezone to UTC+1 and disable DLT, the error does not occur. Regards
Sounds like one of those quirks related to historical time zone changes. @Helmut: From your mail address I deduce that your machine is setup to work in a Europe/Vienna timezone, is this assumption correct? I'm asking because I could not reproduce the error with that timezone, but I could reproduce it using Europe/Berlin. But maybe Windows doesn't differentiate there..
Hi Eike, I am from Vienna, my timezon setting is "(UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien" with "Uhr automatisch auf Sommer-/Winterzeit umstellen" enabled. Windows7 Home Premium 64-bit SP1 Regards Helmut
@Eike: I can reproduce a similar behaviour as your Linux tests also in Windows7. If I set the timezone to "(UTC+01:00) Belgrad, Bratislava, Budapest, Ljubljana, Prag" the problem does not occur. From the registry: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Europe Standard Time] "MUI_Display"="@tzres.dll,-280" "MUI_Dlt"="@tzres.dll,-281" "MUI_Std"="@tzres.dll,-282" "Display"="(UTC+01:00) Belgrad, Bratislava, Budapest, Ljubljana, Prag" "Dlt"="Mitteleuropäische Sommerzeit " "Std"="Mitteleuropäische Zeit " "TZI"=hex:c4,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,03,00,00,\ 00,00,00,00,00,00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\W. Europe Standard Time] "MUI_Display"="@tzres.dll,-320" "MUI_Dlt"="@tzres.dll,-321" "MUI_Std"="@tzres.dll,-322" "Display"="(UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien" "Dlt"="Mitteleuropäische Sommerzeit" "Std"="Mitteleuropäische Zeit" "TZI"=hex:c4,ff,ff,ff,00,00,00,00,c4,ff,ff,ff,00,00,0a,00,00,00,05,00,03,00,00,\ 00,00,00,00,00,00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00 The values of TZ1 are the same, though.
Same problem with the 7.4.1691 (you notice: German, timezone Berlin). The problem doesn't appear with LO 3.5.7.1 I set the Platform to All, All, because I have tested this with a Linux-32bit-rpm-system.
*** Bug 57683 has been marked as a duplicate of this bug. ***
both 1691-04-07 and 1691-04-06 go to 1691-04-06 (but different values are shown if formatted as "number"). Dates before 1691-04-05 are correct! Regards Chris
*** Bug 62683 has been marked as a duplicate of this bug. ***
Timezone offset is 3600000 milliseconds (1h), there was a historical transition from 3208000 milliseconds (53:28) causing a rounding error.
Same cause as bug 44286 *** This bug has been marked as a duplicate of bug 44286 ***