Standardize All Dates On ISO 8601 - how can this be done?

[Ian Leader <__ian.leader__@…>]

This ticket is for one of the issues flagged on completion of #1606. A number of different date formats are now used in trac:

• trac-admin uses YYYY-MM-DD (ISO 8601) for input and display
• the Roadmap module uses DD/MM/YY for input
• the display format for the web interface (including the Roadmap module) depends on your OS/Web Server config

I would suggest that formats be specified (separately for display and input) in trac.ini, probably defaulted to ISO 8601, and these formats be used throughout. Possibly also an option to pick it up from the OS/web server environment.

Any views?

[Matthew Good]

I don't think trac-admin needs configurable date formatting. The YYYY-MM-DD is simple and unambiguous and well suited for the command-line tool. Making it locale-based simply causes problems as seen in #1606, so I think we should just stick to the one format.

For the web interface it makes sense to provide locale-based date displays, and the formats for the date inputs should also be consistent. I think this is already the case, but if not please provide examples so that these can be fixed.

I don't think that we need to add an option to trac.ini to provide yet another way to allow the user to configure the locale. This seems redundant since there are already sufficient ways for the user to set their locale so that Python uses the proper date formatting.

[chris@…]

I think the web interface should also follow the ISO 8601 standard. There has been a discussion about the use of dates on the subversion list that I have been a part of and the standard is strongly supported.

I was suprised to find that the milestone web interface uses the american MM/DD/YYY format!

A summary of the standard can be found here: ​http://www.cl.cam.ac.uk/~mgk25/iso-time.html

[Ian Leader <__ian.leader__@…>]

The milestone (roadmap) web interface doesn't have a fixed date format, US or otherwise - it uses the date format of the locale set on the server where trac is running - as do all other parts of the web interface AFAIK.

When I submitted a ticket, I thought there was an inconsistency between the roadmap web interface and the rest of the web interface, but following mgood's response, I could not reproduce, so I think it was an error on my part.

There was some discussion on the mailing list about setting the locale (in the thread starting with ​http://lists.edgewall.com/archive/trac/2004-November/001026.html). What isn't clear to me is whether one can change the locale to use ISCO 8601 dates.

If not, then I think there should be a way to do this in trac.

If there is a way to do this, then it offers one solution to standardising on ISO 8601 (of course it doesn't adress the issue of whether date formats should be set on a server, client or user basis, or whether you should have to change the locale that Apache is running to alter trac's behaviour)

[asmodai@…]

The SetEnv trick is a nice work-around but it doesn't solve the problem at hand:

• humans are more comfortable using their own locale specific date/time formatting rules.

See ​http://www.w3.org/International/questions/qa-date-format

Basically it boils down to: use HTTP_ACCEPT_LANGUAGE sent by the UA (User-Agent) and if not present or the locale is not available on the server to format as expected, fall back to ISO.

[Matthew Good]

#2321 has been marked as a duplicate of this ticket.

[mcarpenter@…]

I have a development team all over the world, and the date system can be very confusing for those not in the US (where our server is and thus the locale set on the server).

Here is how you can get Trac (mod_python on debian) to use ISO 8601:

1. Add the locale "i18n" to your system. (on debian you do this: Edit "/etc/locale.gen" and add a line "i18n ISO-8859-1". Run "locale-gen")
2. Edit your apache config for your trac instance. Add the line "PythonOption TracLocale i18n"
3. Restart apache

[dave@…]

Using the LOCALE options from your host implies you would like to set the date format for an entire server. I work with americans, english and dutch people and we all have different date formats.

The other problem I have is because I use the FastCGI interface, setting whatever environment variable doesn't help.

I would like to see the HTTP_ACCEPT_LANGUAGE method because it's the most practical solution for mixed teams.

[anonymous]

how do you do this on solaris?

[anonymous]

OK I've been trying for some time now to have trac implement the ISO8601 standard.

The locale setting no Windows Server 2000 is set to Canada, and the Date is set to YYYY-MM-DD.

Yet, trac still shows MM/DD/YYYY!!

If I add the line in the apache.conf: "PythonOption TracLocale i18n"…it's CLOSE to the standard, but the seperater is wrong! "20.02.2006"

Does anyone know the "name" for the locale that uses the ISO8601 standards?

Thanks!

[anonymous]

Above date format (with dot as delimiter) is used in Europe (except Britain). And Europeans get very confused about MM/DD/YY….

[Alec Thomas]

chexum on TracHacks has found a locale that has the correct date and time formatting: ro_RO

You can see it in action in ​#H317.

[Christian Boos]

Unfortunately this locale shouldn't be used for Trac, because it has a misleading connotation: the "ro_R" part :)

[anonymous]

ISO 8601 formatting as standard

[mark@…]

Please accept the attached patch for setting date/time format to ISO 8601 by default. It's just a trivial change an users will get less confused.

[mark@…]

This is a more advanced patch against version 0.9.5.

[Emmanuel Blot]

The patch would prevent users from using a localized date.
I don't think it should be merged to the Trunk as-is.

[mark@…]

Currently the users have trouble even setting localized dates. Therefore this patch solves the issue "standardization".

If it is about a better (and configurable) support for custom date/time format, it belongs to a separate ticket. (Ain't it "One Issue per Ticket"?)

[Emmanuel Blot]

I do not have special trouble settings the date to the UK or the FR format, and I really don't want to see some hardcoded format that cannot be modified by a configuration option.

That would simply move the issue, not fix it up.

The patch might be merged if some configurable option came with it, such as:

• if locale is not defined, use "%Y-%M-%d"
• else use "%X"

[Matthew Good]

Mark, maybe the subject is slightly misleading, but if you re-read the original description it specifically asked for an option in trac.ini to set the date format. It wouldn't need to be a trac.ini option if there's a way to do it appropriately via the locale, but an acceptable patch would leave the locale-defined date/time as the default and provide a way to override this to use ISO-format dates and times instead.

[salrae@…]

version 0.10.4

[Christian Boos]

Superseded by #2182.

[salrae@…]

version 0.10.4

[shuusaku@…]

Hi. I am trying to solve this format issue, but no luck so far despite the fact I have extensively looked for information and hints.

At present my Trac environment shows dates in several formats, i.e.:

• MM/DD/YY (which I hate as it is highly ambiguous, especially when working in a international environment) for Timeline, Tickets, Milestones, etc
• DD/MM/YYYY when creating a new ticket
• DD-MM-YYYY hh:mm:ss accepted for milestones, and shown for the Completed field
• DD-MM-YYYY

Most of the hints for the date fields are

Format: MM/DD/YY

However, it seems they also accept the DD-MM-YYYY hh:mm:ss format. The hint for Completed field in milestones, instead, shows

Format: YYYY-MM-DD hh:mm:ss

What I would like to do is:

1. use only one standard, possibly the ISO one
2. change correspondingly all the hints in the web interface

Is it something it is possible to do by myself? Any hint on what I should modify, and how? I tried to play a little bit with /var/lib/python-support/python2.5/trac/util/datefmt.py but couldn't obtain any stable result.

It might be possible that the solution has been already posted somewhere, but I cannot find it. Any help is appreciated. Thanks!

PS: as this issue seems still open to me, I am re-opening the ticket. sorry.

[Christian Boos]

As said above, this will be part of #2182.