localization patch 119408-07 - Solaris

This is a discussion on localization patch 119408-07 - Solaris ; Hi! I installed localization patch 119408-07. This patch significantly change behavior of "date" command under Russian ISO8859-5 (ru) and other locales vs. "C" and en_US.ISO8859-1 locales. Compare: $ LANG=C date Fri Feb 16 18:13:54 MSK 2007 $ LANG=en_US.ISO8859-1 date Fri ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: localization patch 119408-07

  1. localization patch 119408-07

    Hi!

    I installed localization patch 119408-07.

    This patch significantly change behavior of "date" command
    under Russian ISO8859-5 (ru) and other locales vs. "C" and
    en_US.ISO8859-1 locales.

    Compare:

    $ LANG=C date
    Fri Feb 16 18:13:54 MSK 2007
    $ LANG=en_US.ISO8859-1 date
    Fri Feb 16 18:18:40 MSK 2007
    $ LANG=en_US date
    Fri Feb 16 18:18:40 MSK 2007

    vs.:

    $ LANG=en_GB date
    Friday, 16 February 2007 18:16:05 MSK
    $ LANG=ru date
    16 ??????? 2007 ?. 18:18:01 MSK
    $ LANG=ru_RU.ISO8859-5 date
    16 ??????? 2007 ?. 18:19:13 MSK
    $ LANG=fr date
    vendredi 16 f?vrier 2007 18 h 20 MSK
    $ LANG=es date
    viernes 16 de febrero de 2007 18H21'34" MSK
    $ LANG=de date
    Freitag, 16. Februar 2007 18:22 Uhr MSK

    All program which use 3 positions for month name and day of
    week name need to be modified!

    This is not good

    Vitaly Filatov, Moscow

  2. Re: localization patch 119408-07

    Vitaly Filatov wrote:
    >I installed localization patch 119408-07.
    >
    >This patch significantly change behavior of "date" command
    >under Russian ISO8859-5 (ru) and other locales vs. "C" and
    >en_US.ISO8859-1 locales.
    >...
    >This is not good


    Not good for sure, but that's POSIX.

    Problem is POSIX is not comprised of systems administrators but of
    programmers. These POSIX re/engineers neither know nor care how many
    sysadmin tools they break or how many useful commands they deprecate.
    They are driven to change perfectly functional software "because they
    can". Sadly, OS vendors wishing to claim "full POSIX compliance" are
    forced to adopt the flawed "standards" and we all have to suffer the
    consequences.

    Peter



    >Compare:
    >
    >$ LANG=C date
    >Fri Feb 16 18:13:54 MSK 2007
    >$ LANG=en_US.ISO8859-1 date
    >Fri Feb 16 18:18:40 MSK 2007
    >$ LANG=en_US date
    >Fri Feb 16 18:18:40 MSK 2007
    >
    >vs.:
    >
    >$ LANG=en_GB date
    >Friday, 16 February 2007 18:16:05 MSK
    >$ LANG=ru date
    >16 ??????? 2007 ?. 18:18:01 MSK
    >$ LANG=ru_RU.ISO8859-5 date
    >16 ??????? 2007 ?. 18:19:13 MSK
    >$ LANG=fr date
    >vendredi 16 f?vrier 2007 18 h 20 MSK
    >$ LANG=es date
    >viernes 16 de febrero de 2007 18H21'34" MSK
    >$ LANG=de date
    >Freitag, 16. Februar 2007 18:22 Uhr MSK
    >
    >All program which use 3 positions for month name and day of
    >week name need to be modified!
    >
    >This is not good
    >
    >Vitaly Filatov, Moscow


  3. Re: localization patch 119408-07

    2007-02-19, 01:12(+00), :
    > Vitaly Filatov wrote:
    >>I installed localization patch 119408-07.
    >>
    >>This patch significantly change behavior of "date" command
    >>under Russian ISO8859-5 (ru) and other locales vs. "C" and
    >>en_US.ISO8859-1 locales.
    >>...
    >>This is not good

    >
    > Not good for sure, but that's POSIX.
    >
    > Problem is POSIX is not comprised of systems administrators but of
    > programmers. These POSIX re/engineers neither know nor care how many
    > sysadmin tools they break or how many useful commands they deprecate.
    > They are driven to change perfectly functional software "because they
    > can". Sadly, OS vendors wishing to claim "full POSIX compliance" are
    > forced to adopt the flawed "standards" and we all have to suffer the
    > consequences.

    [...]

    I don't follow you. POSIX aims at aiding portability.

    POSIX doesn't forbid date output to be the same in Russian or US
    english locales. However it clearly defines what the output
    should be in the POSIX or C locale.

    So, it's not making "date" conformant that broke the OP's script
    it's making "date" localized that did it.

    The OP's script was wrong to assume he could rely on date output
    in non-POSIX locales, not because POSIX makes sure the output is
    not what he expects in non-POSIX locales, but because there's
    nothing (neither POSIX nor common sense) that guarantees the
    output format in non-standard locales.

    On the contrary, thanks to POSIX, he can now be assured that as
    long as he forces the locale to be POSIX, the date output format
    will be consistent from system to system.

    LC_ALL=C date +%b

    will return "Feb" (or whatever the month is in the user's
    timezone) whatever the system (as long as you're in a POSIX
    environement on that POSIX compliant system).

    And

    LC_ALL=C date -u +%b

    will return the month in the universal time zone.

    Without POSIX, how would you want to guarantee anything?

    --
    Stéphane

  4. Re: localization patch 119408-07

    Stephane CHAZELAS wrote:
    > 2007-02-19, 01:12(+00),
    > I don't follow you. POSIX aims at aiding portability.
    >
    > POSIX doesn't forbid date output to be the same in Russian or US
    > english locales. However it clearly defines what the output
    > should be in the POSIX or C locale.
    >
    > So, it's not making "date" conformant that broke the OP's script
    > it's making "date" localized that did it.
    >
    > The OP's script was wrong to assume he could rely on date output
    > in non-POSIX locales, not because POSIX makes sure the output is
    > not what he expects in non-POSIX locales, but because there's
    > nothing (neither POSIX nor common sense) that guarantees the
    > output format in non-standard locales.
    >
    > On the contrary, thanks to POSIX, he can now be assured that as
    > long as he forces the locale to be POSIX, the date output format
    > will be consistent from system to system.
    >
    > LC_ALL=C date +%b
    >
    > will return "Feb" (or whatever the month is in the user's
    > timezone) whatever the system (as long as you're in a POSIX
    > environement on that POSIX compliant system).
    >
    > And
    >
    > LC_ALL=C date -u +%b
    >
    > will return the month in the universal time zone.
    >
    > Without POSIX, how would you want to guarantee anything?
    >

    Thank you!

    I do it in the same manner, when I'm writing my skripts.

    But I wanted to say that after this patch some X-programs obtain wrong
    behavior.

    Vitaly Filatov

  5. Re: localization patch 119408-07

    In alt.solaris.x86 Stephane CHAZELAS wrote:
    >I don't follow you. POSIX aims at aiding portability.


    Might be true from a data structure and algorithm perspective but clearly
    not true from the point of view of a systems administrator. What,
    for example, is portable about variable width D.O.M and D.O.W fields?
    What about the word "abbreviation" do POSIX re/engineers not understand?

    >POSIX doesn't forbid date output to be the same in Russian or US
    >english locales. However it clearly defines what the output
    >should be in the POSIX or C locale.


    Not the problem we are talking about here.

    >Without POSIX, how would you want to guarantee anything?


    Pure FUD. POSIX doesn't guarantee backwards compatibility, it breaks it.

    For a few other examples: why has POSIX "deprecated" the nslookup command,
    and sort's -M? Why have they "deprecated" sort flags beginning with "+"?
    For another example, where POSIX specifies 'LANG=fr date':

    viernes 16 de febrero de 2007 18H21'34" MSK

    it could have specified:

    Ven Fev 16 18:18:40 MSK 2007

    and retained backwards compatibility. Just for starters...

    Make no mistake, POSIX is a relatively small group of C programmers with
    little or no systems administration experience, making no effort to seek
    end-user input on proposed changes. This has always been a problem with
    the IEEE. Just this once you would think they could learn something
    from the IETF's more successful and inclusive methodology.

    Peter

  6. Re: localization patch 119408-07

    2007-02-20, 19:08(+00), :
    > In alt.solaris.x86 Stephane CHAZELAS wrote:
    >>I don't follow you. POSIX aims at aiding portability.

    >
    > Might be true from a data structure and algorithm perspective but clearly
    > not true from the point of view of a systems administrator. What,
    > for example, is portable about variable width D.O.M and D.O.W fields?
    > What about the word "abbreviation" do POSIX re/engineers not understand?


    I have no clue what you're talking about.

    >>POSIX doesn't forbid date output to be the same in Russian or US
    >>english locales. However it clearly defines what the output
    >>should be in the POSIX or C locale.

    >
    > Not the problem we are talking about here.


    I beleive someone said: since my system was upgraded for POSIX
    compliant, the Russian locale breaks my script.

    POSIX doesn't specify what the output of date should be in the
    Russian locale, so it can't be, that's what I was saying.

    >
    >>Without POSIX, how would you want to guarantee anything?

    >
    > Pure FUD. POSIX doesn't guarantee backwards compatibility, it breaks it.


    ???

    > For a few other examples: why has POSIX "deprecated" the nslookup command,
    > and sort's -M? Why have they "deprecated" sort flags beginning with "+"?
    > For another example, where POSIX specifies 'LANG=fr date':


    You may be confused. There has never been any nslookup or any
    name resolution command specified by POSIX, AFAIK.

    AFAIK, there's no network related command specified by POSIX

    I think the vendors of bind (the ISC at least initially)
    deprecated nslookup for their new software "dig". As far as I
    know, there's no standard behind it.

    > viernes 16 de febrero de 2007 18H21'34" MSK
    >
    > it could have specified:
    >
    > Ven Fev 16 18:18:40 MSK 2007
    >
    > and retained backwards compatibility. Just for starters...


    Again, POSIX doesn't specify the output of date in the Spanish or
    Russian locale, certainly it can't be blamed for that, you seem
    confused again.

    > Make no mistake, POSIX is a relatively small group of C programmers with
    > little or no systems administration experience, making no effort to seek
    > end-user input on proposed changes. This has always been a problem with
    > the IEEE. Just this once you would think they could learn something
    > from the IETF's more successful and inclusive methodology.

    [...]

    What are you talking about? Maybe you're confusing POSIX with
    something else?


    --
    Stéphane

+ Reply to Thread