[Top][All Lists]
[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.