bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH] "date" malfunctions in the Turkish locale


From: Jim Meyering
Subject: Re: [PATCH] "date" malfunctions in the Turkish locale
Date: Mon, 04 Aug 2008 08:44:43 +0200

Bruno Haible <address@hidden> wrote:
>> Here's a proposed patch to solve the problem without changing locale.
>> Since tables are all ASCII, we can simply use c_toupper instead
>> of toupper.  While not necessary, I've gone ahead and changed to
>> c_isspace and c_isalpha as well.  Any application that relies on getdate
>> skipping leading white space characters not in the ASCII set already has
>> locale-dependent bugs.  In other words, while this change does restrict
>> the input grammar slightly, it is for a good cause: making the grammar
>> locale-independent.
>>
>> Barring objections, I'll push this on Monday.
>
> The patch is good (btw it requires an additional dependency in 
> modules/getdate),

Hi Bruno,

Thanks.  I've added that.

> because the getdate.y code is not yet internationalized: Only English month
> and weekday names are accepted, not localized ones.
>
> In a german locale,
>   $ date -d Tuesday
>   Di Aug  5 00:00:00 CEST 2008
>   $ date -d Dienstag
>   date: ungültiges Datum „Dienstag“
>
> When the getdate.y code is internationalized, special care must be taken
> because there are some Turkish month names that include an 'i'. These are
> the abbreviated names from the glibc locale:

I'm sure some applications would welcome an internationalized
get_date function, but if you work on that, please ensure that the
internationalized weekday/month-name-parsing code is optional.
For GNU date, I am reluctant to add a feature that will let users write
date-parsing scripts that work in their own locale, but that fail in
any other.  GNU sort's month-name-parsing code is in the same situation.




reply via email to

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