Bug TDF#99097 <https://bugs.documentfoundation.org/show_bug.cgi?id=99097> The source of the problem comes from source code LO which interprets the code NN (nn) as the abbreviation of the day whereas VBA interprets the code NN like minutes. Codes definition in LO are: sKeyword[NF_KEY_M] = "M"; // month 1 sKeyword[NF_KEY_MM] = "MM"; // month 01 sKeyword[NF_KEY_NN] = "NN"; // *Day of week short* sKeyword[NF_KEY_NNN] = "NNN"; // Day of week long In the BASIC machine we have the following definition when the format code NN is alone. In particular, when the NN code is not embedded in the year and day codes, in which case the decoding of LO applies. #define VBAFORMAT_N "n" #define VBAFORMAT_NN "nn" *Where n and nn are interpreted like minutes.* So we have to decide here the desired behavior of the BASIC machine when the N or NN code is in the string of a format. Do we stick to LO and then the only way to get the minutes is to use the M or MM code? In this case, we will have a possible collision with the code for the months. Or should we look for compatibility with VBA? It seemed possible to me to code an exception to obtain the desirable behavior (compatibility with VBA) of the codes "N" and "NN". But, I do not like this approach. Especially since LO's special use of the "N" and "NN" codes does not seem useful to me and could be abandoned. I have attached a Calc file that reproduces the Date/Time codes as encoded in the /libreoffice/svl/source/numbers/zforscan.cxx file. I highlighted the problem codes related to the bug. So, my question is: what do you think? Regards
Attachment:
Format_Code
Description: Binary data