Re: Formatting a date/time string

[Roozbeh Pournader <roozbeh farsiweb info>]

On Thu, 2005-12-29 at 18:08 -0800, Rick Stockton wrote:
> 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).

The timezone abbreviations become 4 characters in some cases. Generally,
you can't assume anything about them, specially if it could become
localized. for example, the localized version of Iranian timezone to
Persian, is usually three *words*.

> (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.

No. Actually some locales (including Persian) don't even have an
abbreviation for weekdays.

> Is 24 hour clock formatted as "hh:mm" universally understood? I
> suspect that it *is*.

Not necessarily. You shouldn't assume it is universally understood.

> > 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).

No, you are not hard coding the WEIRD en-us as the standard. This is the
way gettext works. You should use whatever is more appropriate in the
en_US locale, and at the same time let localizers localize that. This is
the way it has been working in GNOME for ages. Developers shouldn't try
to do something that is "acceptable" to all locales, they should provide
localization mechanisms.

roozbeh