Bug TDF#99097 - Call for reflection

[Pierre Lepage]

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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/libreoffice

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20161230/d79b9c34/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Format_Code
Type: application/octet-stream
Size: 23363 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20161230/d79b9c34/attachment.obj>