140814 - Page info show ambiguous dates when there is no locale set

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Cesar Eduardo Barros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020426
BuildID:    2002042610

The page info shows as MM/DD/YY. This is terribly confusing when the day is
below 12 -- how can I know just by looking at the page that it's the
brain-damaged USian MM/DD/YY encoding and not the way we're taught at school
(DD/MM/YY)?

Reproducible: Always
Steps to Reproduce:
1. Open the URL
2. Open Page Info

Actual Results:  
Modified: 04/09/01 08:06:20
Expires: 06/06/02 09:09:33

Expected Results:  
Modified: 2001-Apr-09 08:06:20
Expires: 2002-Jun-06 09:09:33

Comment 1

[Cesar Eduardo Barros]

An alternative would be the HTTP format like "Sun, 06 Nov 1994 08:49:37 GMT",
which also includes the weekday and the timezone.

BTW, the format I've seen appears with no locale (except LC_CTYPE) set. I think
the format should not depend on the locale (or at least not be ambiguous; a
non-ambiguous version of that one would use 4-digit years and three-letter months)

Comment 2

[Boris Zbarsky [:bzbarsky]]

The date format should absolutely follow whatever the default date format for
the locale is.  Page info just uses the nsIScriptableDateFormat interface to
show the date....

If you don't like the "brain-damaged US date format" (which makes sense) all you
need to do is to set LC_TIME to do the right thing, no?

Comment 3

[Cesar Eduardo Barros]

I agree with following what the locale says, if there's a locale set.

However, there's no locale set. I don't think no locale should be the same as
en_US or en.

The most sane date format is YYYY-MM-DD, and so it's a good choice for when
there's no locale (LANG, LC_ALL and LC_TIME are all unset, which gives a LC_TIME
of "C" according to /usr/bin/locale).

Comment 4

[Boris Zbarsky [:bzbarsky]]

To intl, in that case -- this needs to be fixed in the nsScriptableDateFormat code.

Comment 5

[Daniel Brooks [:db48x]]

correct, not a bug in page info. I request the long date format from
nsIScriptableDateFormat, and on windows I get output like Tuesday, April 30,
2002 7:42:24 AM. However, according to comments in
http://lxr.mozilla.org/seamonkey/source/intl/locale/idl/nsIScriptableDateFormat.idl,
this may not be as easy on other platforms.

Comment 6

[Roy Yokoyama]

Assign to Linux intl for now.
http://lxr.mozilla.org/seamonkey/source/intl/locale/idl/nsIScriptableDateFormat.idl#90

Comment 7

[Yuying Long]

So the problem here is only for there is no locale set, right?
Modify the summary as such.

Page Info. -> change QA to Kasumi.

Comment 8

[Markus Kuhn]

I can reproduce the problem with Build ID 2002051009 (1.0rc2) for Linux.

A plea to U.S. based developers: Mozilla should *never* default to what most
inhabitants of this planet will consider cruel and unusual U.S.-only conventions
(inches, 8.5x11" paper, MM/DD/YY, am/pm, etc.), unless the locale (LANG)
contains explicitely the string "en_US". Please make the hardwired defaults that
are used if no locale is set to use the globally most common and acceptable
standard conventions (millimeters, A4 paper, YYYY-MM-DD, 23:59, etc.).

ISO standard date and time notation:

  http://www.cl.cam.ac.uk/~mgk25/iso-time.html

This has nothing to do with intl, it has to be fixed in the default rules.

Comment 9

[kill this account]

Simply changing the default seems problematic.

Lets be careful and try to avoid "zero sum games"; ie: making one group happy at 
the cost of making another group unhappy.

Comment 10

[Markus Kuhn]

It is not a zero sum game if (1) the vast majority of users will benefit from
the change and (2) if the minority (here: U.S.) practice is very objectionable
on numerous practical grounds (ambiguity, historic obsoleteness, violation of
well-established global standards, etc.). Simply changing the default to match
the relevant ISO standards (ISO 8601 = yyyy-mm-dd hh:mm, ISO 1000 = metric
system, ISO 216 = A4 paper) is the right thing to do here for the default
distribution.

With regard to localization settings, it is very unfortunate that Mozilla ships
currently *only* with an "en_US" setting and getting rid of it is rather
non-trivial. Would it be possible to at least also add an "en" locale, that also
uses English (even US English if you prefer) and uses for all other settings ISO
standards? I believe, that is what the vast majority of users would prefer over
an en_US locale with confusing date formats and a print option that keeps
jumping back to the non-standard Letter size.

At the moment, Mozilla's default settings merely document the worst aspects of
globalization (make everything the American way) and are likely to be met with
broad hostility. I am working with LANG=en_GB and as I user I very much would
prefer to not ever be bothered with US Letter paper, mm/dd/yy, am/pm, inches,
etc. These things should only become visible to users who work with LANG=en_US
(in the case of US Letter also LANG=en_CA) and to *nobody* else.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So.... there is one question here.  Does the "C" locale define a date format?

Comment 12

[kill this account]

I see no problem with the YYYY-MM-DD date format which is what this bug start
out life addressing.

As far as paper size, simply changing the default to A4 would only immediately
generate a new bug demanding it be changed back. That is a zero sum game. I
have seen this sort of thing many-many-many-many times.

Markus, why don't you open a new bug asking for a code enhancement to set the 
default paper size based on the locale?

Comment 13

[Markus Kuhn]

bstell:
> Markus, why don't you open a new bug asking for a code enhancement to set the 
> default paper size based on the locale?

This paper size problem is now Bug 147419

Comment 14

[Eric Maryniak]

See also bug #157497.

Comment 15

[Boris Zbarsky [:bzbarsky]]

*** Bug 178064 has been marked as a duplicate of this bug. ***

Comment 16

[Vincent Lefevre]

I get the same problem, with both the C locale and the POSIX locale.

Comment 17

[Boris Zbarsky [:bzbarsky]]

In the C or POSIX locale, the correct display of a date is "MM/DD/YY".  Just try
compiling and running the following:

#include <stdio.h>
#include <locale.h>
#include <time.h>

int main () {
  char arr[1024];
  time_t now;
  struct tm * ts;

  time(&now);
  ts = localtime(&now);
  setlocale(LC_ALL, "POSIX");
  strftime(arr, 1024, "%x", ts);
  fprintf(stdout, "date: '%s'\n", arr);
}

Comment 18

[Vincent Lefevre]

But could you give a locale that is ISO-8601 compliant? If there is none, there
should be an option to choose between ISO 8601 and the locales.

Comment 19

[Vincent Lefevre]

Hmm... even better: let the user choose entirely the date format (given to
strftime).

Comment 20

[Boris Zbarsky [:bzbarsky]]

Um... NO.  We should be using the same date display as all other programs on the
user's system (Mozilla's not even necessarily using strftime internally, btw;
that's just a simple example of a locale-aware date-to-string function).

At a quick look, the de_AT locale gives the following output: '2002-11-04 06:29:08'

But really, if you have your locale set correctly and the output is wrong,
contact your OS vendor to have your libc fixed; otherwise all apps, not just
Mozilla, will display wrong.

Comment 21

[Vincent Lefevre]

The other programs display the date in a more sensible way. For instance, the
'date' command on my machine displays:

Mon Nov  4 13:31:49 MET 2002

It is not ambiguous, contrary to the date given by Mozilla. So, the problem is
with Mozilla.

Comment 22

[Boris Zbarsky [:bzbarsky]]

"date" by default does not follow the locale, which is a bug, imo.  "Other
programs" would be not "system utilities" like date but "user-level programs"
who are supposed to use the locale.

After all, the point of the locale system is that the user picks their locale
and all programs _automatically_ format dates/numbers/currency/etc. in the way
preferred in that locale, without having to be hardcoded, or fiddled with, or
whatever.

Why not try complaining that Mozilla relies on the fonts exported by the X
server instead of looking for better-looking ones on the hard drive and using
them?  The situation is exactly analogous.

Comment 23

[Vincent Lefevre]

tin, mutt, ls, zsh (for instance) don't follow the locales. Anyway, the locales
as the only solution are a bad solution, as they are not configurable by the
user. And what's the point of strftime (standard C function) if the one should
always use the locales?

Comment 24

[Boris Zbarsky [:bzbarsky]]

The point is that you may want to get only part of a date string (eg if you're
putting a date in three separate form controls on a webpage as is often done). 
Locales are configurable by the user (that is, you can pick your locale).  If
that locale is not doing the right thing, again that is an OS bug. 
Second-guessing the locale just means that on properly configured systems we
would display incorrectly....

Comment 25

[Vincent Lefevre]

Concerning the fonts (comment 22), you're completely wrong. Mozilla allows the
user to choose the fonts he likes (Preferences / Appearance -> Fonts). It should
be the same for the dates.

Comment 26

[Boris Zbarsky [:bzbarsky]]

But the only fonts in that list are the ones the OS says are available.  We
don't go and look for fonts ourselves (unlike, eg, the Flash 6 plugin, which
does and has major issues as a result).  Similarly, we just ask the OS to handle
dates for us.  If your OS is not handling dates the way you like, then this is
obviously a problem in your OS setup....

Comment 27

[Vincent Lefevre]

Ditto for the dates. The standard C function strftime (for instance) gives you a
small subset of all date formats that can be used. For the week days, you won't
look for the corresponding names yourself; strftime (and the corresponding OS
part) will do it for you. The user should be able to choose different date
formats for different applications, depending on the context, just like for the
fonts.

Comment 28

[R.K.Aa.]

*** Bug 252402 has been marked as a duplicate of this bug. ***

Comment 29

[steve]

(In reply to comment #28)
> *** Bug 252402 has been marked as a duplicate of this bug. ***

At least I can find comfort the fact that the Bugzilla system uses the ISO 8601
standard.

The individuals who are insisting on the local date stamp format probably are
not aware just how much of the U.S. has already changed over to 8601.  There are
6 billion people on the planet and less than 200 million (~3% of the population)
interprets a date stamp using the MM/DD/YY or even MM/DD/YYYY formats to be the
old U.S. formats.  This is a no brainer. 

Actually - take this issue to a higher level.  Not only use the 8601 date stamp
within the browser, mail utility, etc., but also add a filter within the browser
and e-mail tool that dynamically changes the brain dead U.S. standards on web
pages to read in 8601 format.  That would be cool.

Comment 30

[Boris Zbarsky [:bzbarsky]]

> And less than 200 million (~3% of the population)
> interprets a date stamp using the MM/DD/YY or even MM/DD/YYYY formats

So all the others have their locale settins set such that they would get the ISO
8601 format anyway, right?  I don't see the problem, in that case.

Comment 31

[Markus Kuhn]

Firefox 3 seems to use something resembling the ctime() or HTTP format now (e.g., "Tue 16 Jun 2009 16:24:36 BST"), so I think this bug can be closed as FIXED as the horrible MM/DD/YYYY notation is gone.

Comment 32

[Vincent Lefevre]

I confirm.

Comment 33

[Simon Montagu :smontagu]

Fixed by bug 374040