Re: clock capplet and nautilus date and time formats

[Peter Nugent <Peter Nugent Sun COM>]

Hi Danilo
yes, I agree the POSIX standard is pretty limited in what you can do
with it.

The reason I asked the question in the first place is that I was
thinking of extending the "Locale and Culture capplet" to wrap glibc
(currently it does ICU only). However, this doesn't make a lot of sense
if most of GNOME is not using the OS's date and time formatting. The
other option would be to extend the capplet further to configure other
app specific stuff.


I had a quick look at KDE and the "Country/Region & Language Control
Center" (which looks pretty much like a glibc interface judging by the
data in it) does provide a mechanism to configure the desktop clock's
date and time format and the file manager date and time format. I assume
they implemented some sort of logic in code to knock off seconds  or
year or whatever when they don't want to display these things.

GNOME's dispersive , inconsistent approach to locale data looks like a
pretty big defect. Most competing desktops have a consistent approach.

thx
Peter



Danilo Šegan ha scritto:
> Hi Peter,
> 
> Today at 12:01, Peter Nugent wrote:
> 
> 
>>I've noticed that neither the clock applet or nautilus take their date
>>and time formats from the underlying OS eventhough the do take the day
>>and month names from it . Is there a reason for this ? and are there any
>>plans to change this so that they do ?
> 
> 
> I'd be strongly opposed to such a change.  We have much bigger control
> of these fields, and locale definitions simply don't provide enough
> options for us.  I.e. for clock applet, we might be interested in the
> following:
>   time with seconds (13:14:15)
>   time without seconds (13:14)
>   date and time, but *without* year (пон, 14. феб, 13:14)
> 
> while locales (in GNU libc, don't know about other systems) provide
> for me only:
> 
>   $ date +%x # d_fmt
>   14.02.2005.
>   $ date +%X # t_fmt
>   13:16:30
>   $ date +%c # d_t_fmt
>   понедељак, 14. фебруар 2005. 13:16:31 CET
> 
> This is simply not enough, and I'd hate to be limited to these options
> (ok, there's also a t_fmt_ampm, but that doesn't apply to my locale).
> 
> Also, it's very hard to change locales (I've been trying to do that
> for GNU libc, which is still the base platform for Gnome, for around
> two years, where the sr_YU locale even includes a plus sign in the
> string, which is clearly wrong), while it's much easier to
> administrate translations.
> 
> As for Nautilus, it's using a larger granularity (i.e. it again has
> messages for "Yesterday", "Last Thursday"), so above options are
> simply not sufficient.
> 
> Yes, in a perfect world we'd have it based on the operating system,
> but we're still far off from perfect world.
> 
> 
>>Most apps seems to be doing their own thing regarding the date and time
>>formats which leads to an icconsistent end user experience. Other
>>desktops have a more cocsistent approach which measn that these things
>>can be made configurable through a single app.
> 
> 
> I think our response has so far been: let translators provide
> consistency instead.  If they feel agree with you, you can ask them
> to use "%x", "%X" and "%c" wherever strftime formats are asked for,
> but I doubt that will happen.
> 
> The step forward might be the "Language and Culture" capplet (part of
> Gnome Control Center, not installed by default), but I think that the
> major problem is the inscalability of locale system used by systems
> Gnome runs on top of.
> 
> 
> We might actually go another route: instead of relying on OS, develop
> a library of supported time and date formats (or simply extend
> g_strftime, or whatever it's called, to support special modifiers in
> addition to %x, %X and %c).
> 
> Cheers,
> Danilo
> _______________________________________________
> gnome-i18n mailing list
> gnome-i18n gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n

-- 
Peter Nugent,
Software Engineer,
Sun Microsystems Ireland Ltd,
Hamilton House,
East Point Business Park,
Dublin 3,
Ireland.
Tel +353.1.8199522
Email: peter nugent sun com