https://bugs.documentfoundation.org/show_bug.cgi?id=40575
--- Comment #24 from Lionel Elie Mamane <[email protected]> ---
(In reply to Eike Rathke from comment #23)
> However, connectivity/source/commontools/dbconversion.cxx still has its own
> date implementation that probably interferes here.
For full clarity, it contains a (re?)implementation of some date utilities, but
no date (data structure) implementation per se.
It uses the same MAX_DAYS mentioned in comment 5 in addDays and subDays, but
frankly I have no idea why. I just ripped out the MAX_DAYS test and it seems to
work fine.
I expect most, if not all, of these utilities would be advantageously replaced
by a call to common tools Date routines.
> My guess is that various database
> related things can't cope with years > 9999 because year might be stored
> using 4 characters, so some extra handling will still be needed there.
LibreOffice doesn't know, and doesn't care, how the database engine stores the
year. It should just throw the value at the database and if the database it
unhappy it will raise an error or truncate the value. Or *maybe* the SDBC
driver (that is the code in connectivity/source/drivers/*). Any code outside of
that (that is generic to "all of Base" or "all database engines") has no good
reason to arbitrarily enforce such a limitation, and I officially give my
blessing to anyone that volunteers to rip it out.
The only thing is that if we construct SQL expressions with dates in them (as
is done e.g. with calls to DBTypeConversion::toDateString, such as in
connectivity/source/commontools/DateConversion.cxx function
DBTypeConversion::toSQLString), then the date MUST be in ISO order
YEAR-MONTH-DAY, and year MUST have at least 4 digits to avoid ambiguity. That
is "AT LEAST", not necssarily "AT MOST".
WORK ON C++-LEVEL INFRASTRUCTURE
1) Remove the MAX_DAYS check from addDays and subDays
(I'm doing that now)
2) Remove the negative value check from addDays and subDays,
unless it makes sense.
3) Replace utilities in dbconversion.cxx by their tools counterpart;
implBuildFromRelative and implIsLeapYear are prime targets.
OTOH toDateString, toTimeString, toDateTimeString probably
belong dbconversion.cxx
(any volunteer?)
4) Keep in dbconversion.cxx only those that have no counterpart
WORK ON FORM CONTROLS
There are two kinds of form controls that can show dates:
1) Formatted field: this should be able to handle the same date range as Calc,
that should be the number of days that fits in C++ "double". If not, that is
to be fixed. One reason they now don't is the MAX_DAYS check,
which I'm removing
2) Date Fields: testing shows the maximum value of the "Date max" property is
01/01/9999. Find out why. Arbitrary limit or actual code limit?
Raise the limit.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
