No, it was THAT day to see myself the difference! Before your reversion.
Image is saved here since then!
Please, can you answer my question, how can I see that in code? I understand everything else; I know that v.7.3.7.2 would show it as before my change, no matter what. But I ask a simple question: how can I see this in code / in a file?
I must revert exactly because your screenshot shows a clear answer to my question that started the thread: yes, that date is user-visible; and so, it must not be changed.
But maybe your answer to how can I reproduce it would tell me something new, that would still allow an improvement, without the revert.
And what is “TesteSerial” code please?
This is the code I did myself folowing @Villeroy answering with
…
Just to see myself the difference. As I had this dummy DB with DATE as a pk.
Thanks!
And thank you to @Villeroy - I must have misread your answer from start.
Sigh, I will think about that…
(???)
There IS a difference of 2 days.
Didn’t you corrected that; for next updates of LB Base of course(???)
My idea was, that that date wasn’t user-visible, only used as intermediate epoch, when taking dates from DBs (in whatever form), and before converting them to a more standard form in LO (like DateTime structure, or the like). I saw a bug existing because of the presence of this difference, but I hoped that there is no way for user to get actual serial dates based on that epoch in their code.
I see now that it’s not that. Meaning, there may exist code (macros) in real life, which assume this 2-day difference; do something to mitigate that… and my change will inevitably break these real applications.
2 Likes
Thanks again!
So now I see how this is exposed in the API / object model.
A data source object implements respective service, which has NumberFormatsSupplier property. That, in turn, has getNumberFormatSettings method, and the object it returns has NullDate property, which may be different for different data sources.
And there seems to be another bug: that property shows me the standard 1899-12-30, where it produces that two-day difference (meaning, that the code actually uses 1900-01-01).
Taking that into account, I better keep my change for now, and instead, try to find out why this discrepancy occurs.
Initially, the concept of converting a SQL database field of type Date to a number seems applicable only within LibreOffice. For example, in PostgreSQL the following statement:
select cast(current_date as numeric)
will return the error
SQL Error [42846]: ERROR: cannot cast type date to numeric
A similar error (ORA-00932) will be returned in Oracle when executing the statement:
select cast(sysdate as number) from dual
Update.
The JDBC standard does not provide for the application of methods getInt, … to fields of the DATE, TIME, TIMESTAMP type.
But what about
private Date jetzt;
jetzt = new Date();
long t = jetzt.getTime();
?
This is the bug which is to be solved:
https://bugs.documentfoundation.org/show_bug.cgi?id=96190
and this is a buggy behavior of table editor, which might be solved also:
https://bugs.documentfoundation.org/show_bug.cgi?id=102945
(there will be entered 2 days in default date every time I click in date field of the editor, if a default date has been set)
1 Like
I have no idea what you mean. Is there something wrong with in now?
@RobertG the latter one is exactly the tdf#167591 I worked on (mentioned in the initial Q).
I think yes you are correct, both should be fixed now.
sokol92 points out that JDBC doesn’t have a conversion. But languages – and Java here – does have it.