Re: Formatting a date/time string

[Abel Cheung <abelcheung gmail com>]

Hi,


On 12/30/05, Rick Stockton <rickstockton reno-computerhelp com> wrote:

>  Yes, it's NASTY-WIDE. My Proposed Patch implements the wider dialog. Both
> "Date/Time" and "Size" are re-sizable columns, which helps a little bit. But
> the key, I think, is to address the internationalized format itself. If we
> have to work from %c (which we probably DON'T, see asterisk section below)
> then I think that:
>
>  the first thing to chop off is the time zone, DEFINITELY not needed;
>  the second thing to chop off is the seconds, (hard to imagine when someone
> would need "seconds" within the filechooser.)
>  And, the 3rd thing I'd like to chop off is the day-of-week.
>
>  If necessary, this leads to 2 questions:
>
>  (1) Are all timezones shown via a 3-character code, or do some locales have
> more characters? (I'm not counting bytes, I'm counting characters). If so,
> we could chop it off inline. I've got a bad feeling that at least one of the
> many-glyph languages (e.g., Chinese), might use just a single character for
> this.

See below.

>
>  (2) Similarly, is it possible that all locales use a 3-character code  for
> Day-Of-Week? Again, I doubt it, but it would be easy to chop off if this was
> true.

Both (1) and (2) may not be true. There exists 4-letter timezone (e.g. HKST)
though I don't really know if anything like that is actively in use. And
you guessed it correctly that some places don't use 3 letters to represent
day of week.

In general, chopping letters off %c is almost certain to cause problem.

>
>
>  If short string is more desired, I'd suggest showing only the time if
> modification time is within 1 day, and only showing the date if more than
> 1 day. And use ISO8601 format for date representation as well:
> "%Y-%m-%d". This avoids ambiguity. For display of time, perhaps
> the seconds part can be removed as well?
>
>  Per above, I really like chopping out the seconds. But showing "time" only
> for today's files doesn't really do any good-- once we've printed a couple
> files with the time included, the column width is set large, and the empty
> space (shown with the other files) wouldn't save room, it would just be a
> visual distraction. More importantly, I think that we'd be cutting out
> useful data.

May I ask: what useful data will be cut out?


>
>  3rd idea, I don't like it. I feel that using ISO8601 is really ugly for
> "non-experts" in the US locale: 2005-10-11 is clearly the 11th of October,
> but almost *EVERY* other program they've used, especially if they come from
> Windoze, shows m/d/y. Too radical and upsetting, I think.

For other countries, I'd disagree; but for US people, then I also think you're
correct.


>  I'd say try to use %x and/or %X for dates and times. They usually
> produce shorter string representations than the %c specifier.
> Unfortunately, there is no standard specifier that produces a
> localized time string without the seconds part... :-(
>
>  *********************** THANK YOU !!!! ********************
>
>  How about %x (local-appropriate date),
>
>  preceded by %R (24-hour hh:mm) ???
>
>
>  if %x leaves out stuff which we don't want, like Time Zone, but handles
>  correct MM/DD/YYYY versus YYYY/MM/DD according to the locale, I think that
>  further adjustments are low priority.
>  (But I'm a newby, and I can't even spell "i10n".)

Agreed %x would be the better default choice, and I'd be grateful if
it's translatable - because on the contrary of most locales, %x is a bad
and ugly choice for Taiwan and Hong Kong.

About %R: beware that some countries may prefer 12hr notation instead
of 24hr one. I'm not sure what can be done in this area. gnome-panel
currently uses translation to decide whether to use 12 or 24hr.

>
>  Is 24 hour clock formatted as "hh:mm" universally understood? I suspect
> that it *is*.
>  There went the seconds!
> ************************************************************
>
>
>  And of course, make the string translatable is the best thing to do, since
> translators can decide if there are any better date/time representation
> for their own language.
>
>  If any translator is not pleased by the %x date, or the hh:mm time
> preceding it,
>  then we WILL want to go there.

Yes, yes, please :-)

Abel


>  Agreed. If you want to use both %x and %X in the time display, you
> probably have to make it translateable, so that translators can
> reorder the arguments if necessary.
>
> However, this sucks for users who only want to have the display
> language be something different (LC_MESSAGES), but otherwise want to
> have times etc. be formatted according to their own locale, since
> doing it like this and hooking up the date/time display in the
> translations makes the time display be dependant on the display
> language. But it is probably the best thing to do right now, until we
> have something better.
>
> Christian
>
>  I don't have any idea of the weakness in having locale control
> everything...
>  but you do, so I'm all ears. For right now, I think that someone who chose
> "en-us"
>  would accept, with just a little frustration, the resulting (weird)
> MM/DD/YYYY.
>
>
>
>
>
>  The standard way to do it is using whatever makes sense to use for
> United States English that strftime offers (say "%b %e, %y ..."), then
> make it translatable with a comment like: "translators should try to
> make this as short as possible, while mentioning the complete date and
> mentioning both minutes and hours in the translation". Something like
> that.
>
>
>  I *don't* like this-- most of the world is YYYY-MM-DD, we shouldn't
> hard-code the WEIRD
>  en-us as the standard. (But mostly, I suspect that we won't have to...
> testing shortly).
>
>
>  We will try to make date and time formatting better in Giulia
> (http://live.gnome.org/LocaleProject), possibly even as the
> first
> priority, but the project is currently inactive because of the very
> limited developer resources.
>
> roozbeh
>
>
>  There are programming errors which I need to fix (this was, after all,
>  my first attempt at C... ever). With Federico's direction,
>  I hope to have a revised patch up tomorrow. I'll try too 'diff' it as an
> actual patch, rather than
>  raw code.
>
>  Question: Is there a reason why we do private email instead of posting to
> the bug?
>
>  Thank you all so much!
>  Rick
>
>
>


--
Abel Cheung   (GPG Key: 0xC67186FF)
Key fingerprint: 671C C7AE EFB5 110C D6D1  41EE 4152 E1F1 C671 86FF
--------------------------------------------------------------------
* GNOME Hong Kong - http://www.gnome.hk/
* Opensource Application Knowledge Assoc. - http://oaka.org/