coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFE: Modification to the Timezone Modifier


From: Marko Myllynen
Subject: Re: RFE: Modification to the Timezone Modifier
Date: Mon, 16 Dec 2013 16:53:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131028 Thunderbird/17.0.10

Hi Sami,

On 2013-12-10 19:56, Sami Kerola wrote:
> On 10 December 2013 12:35, Marko Myllynen <address@hidden> wrote:
>> On 2013-12-10 02:49, Eric Blake wrote:
>>> On 12/09/2013 08:22 AM, Marko Myllynen wrote:
>>>>>> It seems like it would be reasonable to add some sort of modifier to the
>>>>>> existing %:::z to request suppression of leading 0.  If we didn't have
>>>>>> back-compat to worry about, I'd even suggest making %:::z be the short
>>>>>> form, and %0:::z be the 0-padded form.
>>>
>>>>> sorry for the delayed reply and thanks for your insights - I've now
>>>>> filed http://austingroupbugs.net/view.php?id=772 so let's see how it goes.
>>>>
>>>> the request has been rejected on the basis that there are no current
>>>> implementations.
>>>
>>> The rejection also mentioned that an appropriate setting of TZ can
>>> already be used to achieve what you want:
>>>
>>> TZ="<UTC+3>+3<UTC+4>" date
>>>
>>> In other words, if setting TZ is already sufficient, then why
>>> standardize anything else?
>>
>> sorry, I think I was being a bit unclear earlier - I used date as an
>> example but the goal was to be able to adjust the fi_FI locale so that
>> it would produce correct time strings. I've added this clarification to
>> the above request as well.
> 
> I wonder would it be easier to ask Finnish localization recommendation
> group to reconsider the format, with emphasis they should choose
> something that is already supported.

I could easily ask this as I'm a member of the project's steering group
but then personally I would oppose such a proposal :) The rationale
being that computer systems and software should adapt to cultural
conventions not the other way around. There are of course a lot of
related technical issues and room for pragmatism and we might need to
settle with something "close enough" in the GNU/POSIX world with this
for the time being but I don't think providing national recommendations
based on what's currently supported would be the right approach.

Thanks,

-- 
Marko Myllynen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]