Hi Pierre, On Friday, 2016-12-30 06:24:27 -0500, Pierre Lepage wrote:
StarBasic encodes "N" and "NN" as formats different from those of LO, but similar to VBA, ie "N" for minutes without 0 in prefix and "NN" for minutes With 0 in prefix.
Where does it do that? Could you provide a code pointer please?
The first solution appears as a crutch. Coding for an exception will not resolve the source of confusion. Nevertheless, if this solution were to be implemented, the algorithm would have to distinguish between two situations of the codes: a) the codes are embedded in a time format string only in which case the interpretation of the N and NN codes would be in conformity To VBA, that is to say that N would code for minutes without 0 in prefix and NN would code for minutes with 0 in prefix; B) otherwise the codes would be interpreted as they are now, ie NN would code for the abbreviation of the name of the day and N would be ignored.
I'd refrain from such diversion in the number formatter code..
The second solution appears more robust. The confusion would be definitively eliminated. It remains that the historical reason behind the choice of the letters NN and NNN rather than exclusively DDD and DDDD to codify an abbreviated and long day format is unknown to me. It is therefore possible that old files based on the current interpretation of the NN, NNN and NNNN codes will require corrections to rely solely on the DDD and DDDD codes.
Which also is not easily possible, because documents may use format codes relying on the behavior, even worse use such format codes in Calc's TEXT() spreadsheet function as argument.
I included a Calc file summarizing the format codes for dates and time. The first tab is the current situation. The second tab is for the situation once the second solution is implemented. So, before going any further, I need to know the desired orientation for LibreOffice.
I'd change the StarBasic code to pass on modified format codes, H for N and HH for NN. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
signature.asc
Description: PGP signature