https://bugs.documentfoundation.org/show_bug.cgi?id=152118

--- Comment #13 from jcs...@libreoffice.org ---
(In reply to Eike Rathke from comment #12)
> The SQL statement outputs the raw data formatted as date, which is stored in
> the proleptic Gregorian calendar, and apparently dates before 0001-01-01
> (i.e. negative dates or dates BCE) can not be stored in the database (if
> they could in Firebird then someone would have to implement that). The table
> grid view displays data in the locale's calendar.
> 
> > I was supposed to use proleptic Gregorian calendar in Calc
> Calc does not use the proleptic Gregorian calendar. It uses the locale's
> default calendar. As explained in bug 152114 that usually is (does not have
> to be) the Gregorian calendar after the Gregorian cut-off date, and Julian
> calendar before that. If the cut-off date is 1582-10-15 (Gregorian) then
> subtracting 1 from that date yields 1582-10-04 (Julian). Btw, also for Calc
> .ods and other ODF file formats, dates are always stored in the proleptic
> Gregorian calendar.
> 

Now the light has come on and I'm beginning to understand all this mess....

But in any case, it seems to me that most users don't know about calendars and
don't care. I myself was unaware of it and, as you can see, I'm still confused.

But me, and I think most of the users, expect the same data in every place
whatever the calendar is, and whatever was the application that stored the
data.

On the other hand, I think it makes no sense that three dates that are
different in the source (0001-01-01, 0001-01-02 and 0001-01-03) are all stored
as the same date (0001-01-01) instead of showing an error in case the
conversion produces invalid dates for the database.

> To solve this (expectation of display being what's stored) it would need an
> option to force the proleptic Gregorian calendar for display.

That could be a solution, especially in Base, since most databases, it seems,
use the Gregorian proleptic calendar

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to