Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


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 :
Hi

It is vacation time, so please be prepared to wait a bit longer for answers :-)

So, my question is: what do you think?
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.

rgds
jan I.



_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Attachment: Format_Code
Description: Binary data


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.