Created attachment 138200 [details]
test file

Created attachment 138201 [details]
printscreen of error

Already reproducible with OOo 3.3.0 OOO330m20 (Build:9567)

(and actually even with OpenOffice.org 2.2.0)

Actually, it's that way since day 1 (see https://cgit.freedesktop.org/libreoffice/core/commit/?id=c25ec060; look for RTLFUNC(TimeSerial)).

Fixing the code to conform to help is trivial (code is in basic/source/runtime/methods.cxx:2001, void SbRtl_TimeSerial(StarBASIC *, SbxArray & rPar, bool)). But first, it should be clear that the code must be fixed, and not the help. And if the code is to be fixed, then what to do in cases (not covered in help) when hour is in allowed range, and minutes are so that resulting hour becomes outside of the range. Should we allow that? if so, how to go with that, and why should we block hours outside of the range, if this can be processed in a sensible way?

Btw: valid values for hours are 0-24 (24 is converted to 0), not 0-23 as help declares.

Should be fixed for VBA compatibility, at least
https://msdn.microsoft.com/en-us/vba/language-reference-vba/articles/timeserial-function

Not convinced.

The MS documentation is self-contradictory. First, it declares constraints for hours. Then it declares that *each* parameter can be any number between -32768 and 32767. Ant in the same time, it puts some strange limitation that resulting *date* should not fall outside the acceptable range of dates, which cannot occur inside of the 16-bit number arguments (they fall inside 1896-1903)!

So at least, clear specification is required.

Hi raal, Mike, How should be proceed here? Should it be moved to NEW or to
RESOLVED WONTFIX ? Could you please clarify ?

This should be NEW - but clear spec is required.

@Eike, I thought you might be interested in this issue

Seems the implementation is the linked VBA reference "each TimeSerial argument should be in the normal range for the unit; that is, 0–23 for hours and 0–59 for minutes and seconds" part, not considering the following any 16-bit integer is possible for each argument. The "if the time specified by the three arguments causes the date to fall outside the acceptable range of dates, an error occurs." sounds as if more than 24 hours are possible; Excel doesn't handle negative dates so a resulting value of <0 would not be possible, but how about VBA? And what about values >=0 24 hours?

@Mike, can you check?

Our own help says the individual arguments can have any numeric value, but also restricts the result to be between 0 and 0.9999999999 (which in this case is between 00:00:00 and 23:59:59). This actually make most sense to me and IMHO implementation should follow that.

Created attachment 151960 [details]
Testing results with Excel 2016

The code tested was:

> Sub testTimeSerial()
>   Dim result As String
>   Dim i As Long
>   Dim h As Long, m As Long, s As Long
>   For h = -30 To 30 Step 2
>     For m = -70 To 70 Step 10
>       For s = -70 To 70 Step 10
>         i = i + 1
>         Cells(i, 1) = h
>         Cells(i, 2) = m
>         Cells(i, 3) = s
>         Cells(i, 4) = testImpl(h, m, s)
>       Next s
>     Next m
>   Next h
> End Sub
> 
> Function testImpl(h As Long, m As Long, s As Long) As String
>   On Error GoTo errHandler
>   testImpl = TimeSerial(h, m, s)
>   Exit Function
> errHandler:
>   testImpl = "Error: " & Err
> End Function

https://docs.microsoft.com/en-us/office/vba/language/reference/user-interface-help/timeserial-function

The current implementation is here:

https://opengrok.libreoffice.org/xref/core/basic/source/runtime/methods.cxx?r=7201db41#1981

sal_Int16 nHour = rPar.Get(1)->GetInteger();
if ( nHour == 24 )
{
    nHour = 0;                      // because of UNO DateTimes, which go till 24 o'clock
}
sal_Int16 nMinute = rPar.Get(2)->GetInteger();
sal_Int16 nSecond = rPar.Get(3)->GetInteger();
if ((nHour < 0 || nHour > 23)   ||
    (nMinute < 0 || nMinute > 59 )  ||
    (nSecond < 0 || nSecond > 59 ))
{
    StarBASIC::Error( ERRCODE_BASIC_BAD_ARGUMENT );
    return;
}

So we have just to agree on the behaviour of the function :)

Cases where hh > 24 exist in Japan and Norway:
https://fr.wikipedia.org/wiki/Syst%C3%A8me_horaire_sur_24_heures

Note: I did not find similar english page, sorry for the french

Note that ss > 59 is possible too

incomplete english information:
https://en.wikipedia.org/wiki/24-hour_clock?oldid=351779978

Dear raal,

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