Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[nicolas . mailhot]

- Mail original -
De: "Rafal Luzynski" 
> Hi Rafal
>
>
> > Does that mean it is finally possible for a user to set its default
> > date format to ISO 8601 without switching its language to Danish English?
> > [...]

> No, this was not a part of my work. I was working only on how the
> month names are spelled in different languages. I was not even aware
> that the problem of ISO 8601 date exists. Does it solve your problem
> if you set LC_TIME environment variable to en_DK or some other language?
> It would allow you to keep the rest of the system in your default language.

IIRC this didn't work because instead of just switching datetime to -mm-dd 
it also switched the natural language names of days and months to Danish 
English. Most iso 8601 users want the numeric datetime formats changed 
(yearmonthday, week number and so on), not the natural language  parts. I can 
retest but your suggestion does not look like it would work.

Of course I'm not a glibc localization specialist, I may be wrong, it all looks 
like black magic for a layman like me :(

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

24.01.2018 10:08 nicolas.mail...@laposte.net wrote:
>
>
> Hi Rafal
>
>
> Does that mean it is finally possible for a user to set its default
> date format to ISO 8601 without switching its language to Danish English?
> [...]

No, this was not a part of my work. I was working only on how the
month names are spelled in different languages. I was not even aware
that the problem of ISO 8601 date exists. Does it solve your problem
if you set LC_TIME environment variable to en_DK or some other language?
It would allow you to keep the rest of the system in your default language.

Recently I have suggested to introduce en_EU instead of en_DK, this
could save some people from being confused and ask "what is that Danish
English and why should I use it". But that's a different story.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Florian Weimer]

On 01/24/2018 10:08 AM, nicolas.mail...@laposte.net wrote:

Does that mean it is finally possible for a user to set its default date format 
to ISO 8601 without switching its language to Danish English? Windows has been 
allowing that for ages (which is only sensible, since iso 8601 is an 
international standard, and numeric date representation should not depend on a 
particular language).


No, that is an unrelated feature which has not yet been implemented.

Particularly challenging is the choice of week day names and their 
abbreviations.  Do you know what Windows does for them?


I assume that Windows does not use actual ISO 8601, with a 'T' 
separator, and minutes and seconds in the range of 01 … 60 (instead of 
00 … 59).  The later was a mistake, but 'T' is still an integral part of 
ISO 8601 today, but so far, I have not seen anyone requesting ISO 8601 
date format actually wanting it.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[nicolas . mailhot]

Hi Rafal


Does that mean it is finally possible for a user to set its default date format 
to ISO 8601 without switching its language to Danish English? Windows has been 
allowing that for ages (which is only sensible, since iso 8601 is an 
international standard, and numeric date representation should not depend on a 
particular language).

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

24.01.2018 07:10 Florian Weimer  wrote:
>
> On 01/22/2018 11:58 PM, Rafal Luzynski wrote:
> > I'd like to notify you that today I've finished my works on date
> > formatting in glibc, that means upstream. These changes are already
> > arriving to Fedora Rawhide (they should be there tomorrow) and will
> > be part of Fedora 28. They will be included in glibc 2.27 (to be
> > released on February 1), or in pre-release upstream version
> > 2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48).

BTW, thank you Florian for delivering it to Rawhide so quickly.

> Note that this is an ongoing effort.

That's true, the change is visible only in languages where the locale
data have actually changed. That's the reason why I'm asking the language
communities for their opinion before we apply the change. So far only
Polish language has been updated and there is some interest from
Belarisuan and Russian communities but no final approval yet.

> Some Romance languages will
> eventually use this to correct the incorrect spelling of “de April” into
> “d'April”. Once this happens, it will be necessary to change
> translation strings for these languages from “de %B” to “%B”, otherwise,
> the result will “de d'April”.

That's true. So far I have identified three languages where the change
will look like this: Asturian, Catalan, and Walloon.

> (Yes, the meaning of %B changed in a backwards-incompatible way, and
> glibc upstream deliberately implemented it this way.)

That's true. But another argument is that it has never been specified
whether %B is standalone or in-full-date-context. Probably because there
was no such need in Germanic languages. It seems that translators have
always treated this as a standalone version, probably except the Lithuanian
community.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Florian Weimer]

On 01/22/2018 11:58 PM, Rafal Luzynski wrote:

I'd like to notify you that today I've finished my works on date
formatting in glibc, that means upstream. These changes are already
arriving to Fedora Rawhide (they should be there tomorrow) and will
be part of Fedora 28. They will be included in glibc 2.27 (to be
released on February 1), or in pre-release upstream version
2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48).


Note that this is an ongoing effort.  Some Romance languages will 
eventually use this to correct the incorrect spelling of “de April” into 
“d'April”.  Once this happens, it will be necessary to change 
translation strings for these languages from “de %B” to “%B”, otherwise, 
the result will “de d'April”.


(Yes, the meaning of %B changed in a backwards-incompatible way, and 
glibc upstream deliberately implemented it this way.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HEADS UP] Changes in date formatting (strftime, nl_langinfo)

[Rafal Luzynski]

I'd like to notify you that today I've finished my works on date
formatting in glibc, that means upstream. These changes are already
arriving to Fedora Rawhide (they should be there tomorrow) and will
be part of Fedora 28. They will be included in glibc 2.27 (to be
released on February 1), or in pre-release upstream version
2.26.9000-1145 (in Fedora Rawhide: 2.26.9000-48).

What has been changed:

* strftime() family (including stftime_l(), wcstime(), wcstime_l(),
strptime() etc.): there are new format specifiers: %OB, %Ob, %Oh.
It has been specified that the currently existing format specifiers:
%B, %b, and %h generate the month names (%B--full month names, %b
and %h--abbreviated month names) in a grammatical form required when
the month is used as a part of a complete date (that means: together
with the day number) while the new format specifiers with %O (note:
this is O letter, the uppercase o, not the zero digit, 0) will generate
the month names in a grammatical form required when the month is named
by itself (without a day number, usually standalone). In most of the
languages there is no difference between those two forms. However,
there is a group of languages (about 20) where the correct form used in
the full date is a genitive case while standalone months must be
in a nominative case.

* strptime(): just accepts the new format specifiers: %OB, %Ob,
and %Oh; each of them recognizes any form of the month name.

* nl_langinfo() family (including nl_langinfo_l()): there are new
constants supported: ALTMON_1, ALTMON_2, … ALTMON_12, and also (kinda
undocumented): _NL_WALTMON_1, _NL_WALTMON_2, …, _NL_WALTMON_12;
_NL_ABALTMON_1, _NL_ABALTMON_2, …, _NL_ABALTMON_12; _NL_WABALTMON_1,
_NL_WABALTMON_2, …, _NL_WABALTMON_12. These new constants generate
the same month names as strftime() with %OB, %Ob, and %Oh format
specifiers (month names standalone, which means a nominative case
in some languages). The old constants MON_1, MON_2, …, MON_12,
ABMON_1, ABMON_2, …, ABMON_12 generate the same month names
as strftime() with %B, %b, and %h format specifiers--nothing new,
it has been the same since forever. But from now these constants
will generate the month names in a form used when the month name
is a part of a complete date. That means they are unsuitable to
generate the list of months standalone.

What needs to be changed:

* In Fedora: literally, nothing. The changes belong to upstreams
and I'm writing here in hope that some upstream developers are here
as well or you can forward the message to them. But of course
upstream software eventually lands in Fedora (as well as in other
distros). You may add "Requires: glibc >= 2.27" to the packages
which rely on this new feature, that means if their upstreams required
any changes in nl_langinfo() or strftime() calls.

* Translators: if you want this feature to be supported in your
language please notify me ASAP. There will be no change in the
languages for which the locale data in glibc are not changed.
So far only Polish language has been updated. Here is the list of
languages which probably need the update (the list may be incomplete):
Armenian, Asturian, Belarusian, Catalan, Croatian, Farsi, Greek,
Kashubian, Lithuanian, Ossetian, Russian, Scottish Gaelic,
Silesian, Sorbian (Upper and Lower), Ukrainian, Walloon.
These languages probably do not need the change but should put
their attention: Bosnian, Czech, Finnish, Serbian, Slovak.

* Applications using nl_langinfo() to display months: well, you
shouldn't use this function. This is a low-level function useful
to implement strftime(). But if you really want to you can but
you should stop using MON_* (and ABMON_*) and switch to ALTMON_*
(and _NL_ABALTMON_*) instead. You should detect whether it is
supported at compile time or at runtime. Well, it's tricky,
isn't it? Therefore it's better to use strftime().

* Applications using strftime() to format dates: if you display
a full date, including both the day number and the month name,
that is when the format specifier is "%d %b %Y" or "%B %e %Y"
or anything looking like that--no change is required. The only
case is when you display the month name standalone, whether it's
full ("%B") or abbreviated ("%b", "%h"), even when the year
number is included ("%B %Y"). This should be changed to "%OB"
and "%Ob".

* Other libraries than glibc which wrap or reimplement the same API
(like glib2 or gnulib): should enable this or apply the changes
to their implementation. By "enable" I mean "define the new
constants and do not raise an error when you see them or when
you see the %O[Bbh] format specifiers in strftime()".

* Other programming languages: the same as above, that means:
if your language just calls nl_langinfo() and strftime()
then make sure it calls it properly, defines the new constants
and does not raise errors, or if it implements the same feature
then the changes must be applied to your implementation.

* Testers: make sure the dates are displayed correctly, especially