Bug 117878 - Change of behaviour in function DateSerial.
Summary: Change of behaviour in function DateSerial.
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Macro-StarBasic
  Show dependency treegraph
 
Reported: 2018-05-29 12:44 UTC by Luis
Modified: 2023-11-22 03:13 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document. (12.30 KB, application/vnd.oasis.opendocument.text)
2018-06-22 20:50 UTC, Luis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luis 2018-05-29 12:44:56 UTC
Description:
As indicated on the page https://help.libreoffice.org/3.3/Basic/DateSerial_Function_Runtime
if the day parameter of the function is in the range 1-31 no error is returned even if the day is not valid for the specified month and year.
But now if the day is incorrect the function fails. For example DateSerial (2017,02,29).

Versión: 6.0.4.2
Id. de compilación: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf
Subprocs. CPU: 2; SO: Windows 6.1; Repres. IU: predet.; 
Configuración regional: es-ES (es_ES); Calc: group

Actual Results:  
Function fails.

Expected Results:
Not error returned.


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Comment 1 Buovjaga 2018-06-21 16:05:24 UTC
Please attach a document with an example use so we can see the failure.

Please attach an example document.
Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.
Comment 2 Luis 2018-06-22 20:50:28 UTC
Created attachment 143053 [details]
Test document.
Comment 3 Luis 2018-06-22 20:51:26 UTC
Test document provided.
The document has 5 buttons with attached macros:

Button 1: "Call DateSerial(2018,02,28)" macro that calls function DateSerial(2018,02,28)

Button 2: "Call DateSerial(2018,02,29)" macro that calls function DateSerial(2018,02,29)

Button 3: "Call DateSerial(2018,02,30)" macro that calls function DateSerial(2018,02,30)

Button 4: "Call DateSerial(2018,02,31)" macro that calls function DateSerial(2018,02,31)

Button 5: "Call DateSerial(2018,02,32)" macro that calls function DateSerial(2018,02,32)

Results on LO 5.3.0.3 (correct behavior):

Pressing button 1 returns the date of February 28
Pressing button 2 returns the date of March 1
Pressing button 3 returns the date of March 2
Pressing button 4 returns the date of March 3
Pressing button 5 halts macro with the error message: "Action not supported. Invalid procedure call."

Results on LO 5.4.0.3 and 6.4.0.2 (incorrect behavior):

Pressing button 1 returns the date of February 28
Pressing button 2, 3, 4 or 5 halts macro with error message "Action not supported. Invalid procedure call."
Comment 5 himajin100000 2018-06-23 03:59:27 UTC
minor note: I haven't checked how implicit type conversion works on StarBasic, but the code provided at least complained about type mismatch. I did Cstr(dDate).
Comment 6 himajin100000 2018-06-23 04:01:27 UTC
ah, I just now noticed that String concatenation operator is &, not + in VBA .
Comment 7 Luis 2018-06-23 11:26:35 UTC
Hi himajin100000

¿Are you testing the code in VBA?
Mi test file was made for LibreOffice Basic.

I liked the link to source code. But ¿where is method IsValidDate?

I can see that now must be a strict check of date that was not present before.

I reported this bug because the behavior change of DateSerial breaked a function that I use in a LO application and relied on the previous documented behavior.
Comment 8 Luis 2018-06-24 06:38:38 UTC
I can try to patch this issue myself but who decides the desired bebavior?
Comment 9 raal 2018-06-24 14:56:43 UTC
This seems to have begun at the below commit.
Adding Cc: to Eike Rathke ; Could you possibly take a look at this one?
Thanks
 a831a75b6b64c8064bb357efce185b5fb7aef1c2 is the first bad commit
commit a831a75b6b64c8064bb357efce185b5fb7aef1c2
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Tue May 2 22:33:54 2017 +0200

    source 1b13548f33720d80f53d493f6d70cbcce6b1a0fb
author	Eike Rathke <erack@redhat.com>	2017-05-02 15:53:04 +0200
committer	Eike Rathke <erack@redhat.com>	2017-05-02 15:56:20 +0200
commit 1b13548f33720d80f53d493f6d70cbcce6b1a0fb (patch)
tree 0b797dde491986b97a94b96ed4fb83a6295c1a72
parent d2007136587a8722d0e7045828bca6a6d82fd244 (diff)
BASIC: handle the full tools::Date range from -32768-01-01 to 32767-12-31
Comment 10 Eike Rathke 2018-06-25 18:16:55 UTC
I consider accepting invalid dates as wrong, but.. seems that odd roll-over behaviour was for VBA "compatibility" (and for VBA mode it does work)? But then again, why was 02-31 accepted but not 02-32 (which VBA apparently accepts)? I suspect that was due to the dumb old algorithm.

So, do we want to accept any day (and month) number there and roll over? Or should we restrict to the arbitrary previous margin values 1<=month<=12 and 1<=day<=31? Which IMHO does not make sense and I certainly would not accept any complaint that suddenly also day 32 is accepted..

My take: do the full roll-over if that is what VBA does as well.
Comment 11 Oliver Brinzing 2019-07-17 17:04:43 UTC
i can confirm this with:

Version: 6.2.5.2 (x64)
Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: de-DE (de_DE); UI-Language: en-US
Calc: 

current situation:
according to help, values inside range 1-31 should be accepted, but that is not the case at the moment, and with "Option VBASupport 1" we have a full roll over.

IMO at least the help should be adjusted including a hint what "Option VBASupport" does.
Comment 12 QA Administrators 2021-11-21 03:58:07 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2023-11-22 03:13:48 UTC
Dear Luis,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug