<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Encoding of "N" and "NN" in StarBasic : <br>
    /libreoffice/basic/source/sbx/sbxscan.cxx<br>
    a) #define in lines 654 and 655.<br>
    b) Interpretation of "N" and "NN" in lines 743 to 754.<br>
    <br>
    <span id="result_box" class="" lang="en"><span>Hum.</span> <span>H
        and HH code for hours.</span> <span class="">There is a risk of
        confusion.</span> <span class="">I understand the difficulty of
        reassigning the N and NN codes.</span> <span class="">So why
        not go with two new codes?</span> <span class="">I propose I
        and II (second letter in the word Minute ...).<br>
        <br>
        Pierre<br>
        <br>
      </span></span><br>
    <div class="moz-cite-prefix">Le 2017-01-06 à 14:58, Eike Rathke a
      écrit :<br>
    </div>
    <blockquote
      cite="mid:20170106195853.GJ18728@remotee.erack.redhat.com"
      type="cite">
      <pre wrap="">Hi Pierre,

On Friday, 2016-12-30 06:24:27 -0500, Pierre Lepage wrote:

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
Where does it do that? Could you provide a code pointer please?

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
I'd refrain from such diversion in the number formatter code..

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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.

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
I'd change the StarBasic code to pass on modified format codes, H for
N and HH for NN.

  Eike

</pre>
    </blockquote>
    <br>
  </body>
</html>