Bug 52619 - EDITING: 1 day is subtracted if typed date is before July 26, 1790
Summary: EDITING: 1 day is subtracted if typed date is before July 26, 1790
Status: CLOSED DUPLICATE of bug 44286
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: x86 (IA32) Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 57683 62683 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-28 12:55 UTC by Helmut Leininger
Modified: 2013-03-25 20:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet with wrong results (10.39 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-07-28 12:55 UTC, Helmut Leininger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Helmut Leininger 2012-07-28 12:55:46 UTC
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
Comment 1 Rainer Bielefeld Retired 2012-07-28 15:03:36 UTC
[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)"?
Comment 2 Rainer Bielefeld Retired 2012-07-28 15:13:54 UTC
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 ...
Comment 3 Helmut Leininger 2012-07-30 04:44:04 UTC
Same problem occurs with the DATUM function.

=DATUM(1790;7;24)  gives 23.07.1790

Regards
Comment 4 Helmut Leininger 2012-07-30 19:21:25 UTC
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
Comment 5 Eike Rathke 2012-07-30 19:43:25 UTC
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..
Comment 6 Helmut Leininger 2012-07-30 20:16:22 UTC
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
Comment 7 Helmut Leininger 2012-08-11 05:26:24 UTC
@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.
Comment 8 Robert Großkopf 2012-10-13 10:21:33 UTC
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.
Comment 9 Rainer Bielefeld Retired 2012-11-29 18:40:22 UTC
*** Bug 57683 has been marked as a duplicate of this bug. ***
Comment 10 Chris 2012-12-03 11:55:03 UTC
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
Comment 11 bfoman (inactive) 2013-03-24 16:27:30 UTC
*** Bug 62683 has been marked as a duplicate of this bug. ***
Comment 12 Eike Rathke 2013-03-25 19:46:18 UTC
Timezone offset is 3600000 milliseconds (1h), there was a historical transition from 3208000 milliseconds (53:28) causing a rounding error.
Comment 13 Eike Rathke 2013-03-25 20:09:06 UTC
Same cause as bug 44286

*** This bug has been marked as a duplicate of bug 44286 ***