Hi Jan, Eike and Markus, OK. So I write to Eike and Markus.I reviewed the case analysis and corrected some misinterpretation. So here it is.
Currently, the codes "NN", "NNN" and "NNNN" are represented respectively by the keys NF_KEY_NN, NF_KEY_NNN and NF_KEY_NNNN and serve in LO for the short name of the day (Mon, Tue, Wen ...), the long name of the day without separator and the long name of the day with separator. The keys NF_KEY_DDD and NF_KEY_DDDD already fulfill the need for the abbreviation format of the short name of the day and format of the long name of the day (without separator). In addition, 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. But this code is for a very special situation and not too useful! There is a blatant inconsistency and confusion in the use of N, NN, NNN, NNNN, DDD and DDDD codes.
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.
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.
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.
Regards, Pierre Lepage Le 2016-12-24 à 03:09, Jan Iversen a écrit :
HiIt is vacation time, so please be prepared to wait a bit longer for answers :-)Personally I think we should try to have a consistent behaviour in our code base, however Eike and Markus are the specialist in Calc, and they might have some reasons to do things in a special way.So, my question is: what do you think?rgds jan I. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Attachment:
Format_Code
Description: Binary data