Debugging tdf#167591, I found a variable named STANDARD_DB_DATE, with value of 1900-01-01. It is quite problematic, differing from the most-widely-used value of 1899-12-30. This results in all sorts of ambiguous situations, when it’s not known where the value comes from, and so if a correction is needed.
I want to change STANDARD_DB_DATE to 1899-12-30. Does anyone know, if its old value is somehow exposed to API? Do you ever come across it, when writing your Base macros? Thanks!
Having a record set with today’s date 2025-07-19 in column 1 of a HSQLDB (version 2.4), I can query several data types from that column.
getString(1) → 2025-07-19
getDate(1) → c.s.s.util.Date 2025,07,19
getInt(1) → 45855 which is Calc’s day number of 2025-07-17.
same with getDouble, getLong, getFloat.
This is contrary to a formatted form field bound to the very same date column. When I switch the formatted field to number format 0, it displays 45857, which is the “correct” day number based on NullDate 1899-12-30.
I’m not sure how many macro coders work with numeric representations of database dates. A possible scenario in StarBasic:
x = oRecordset.getLong(1)
y = cLong(Today())
If x-y > 21 then Msgbox "This invoice is more than 3 weeks overdue"
This would be wrong by 2 days and your fix would also fix the macro code.
P.S. same with embedded HSQL, embedded Firebird and HSQL 2.4.