Re: clock capplet and nautilus date and time formats

[danilo gnome org (Danilo Åegan)]

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