Re: Bug TDF#99097 - Call for reflection

Encoding of "N" and "NN" in StarBasic :
/libreoffice/basic/source/sbx/sbxscan.cxx
a) #define in lines 654 and 655.
b) Interpretation of "N" and "NN" in lines 743 to 754.

Hum. H and HH code for hours. There is a risk of confusion. I understand 
the difficulty of reassigning the N and NN codes. So why not go with two 
new codes? I propose I and II (second letter in the word Minute ...).

Pierre


Le 2017-01-06 à 14:58, Eike Rathke a écrit :
> 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