Edgewall Software

Opened 16 years ago

Closed 13 years ago

#1690 closed defect (duplicate)

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

Reported by: Ian Leader <__ian.leader__@…> Owned by: Jonas Borgström
Priority: normal Milestone:
Component: general Version: 0.10.4
Cc: chris@…, dserodio@…, rhind@…, mcarpenter@…, dave@…, shuusaku@… Branch:
Release Notes:
API Changes:
Internal Changes:


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?

Attachments (4)

trac_trunk_ISO8601_date_standard.patch (451 bytes ) - added by anonymous 15 years ago.
ISO 8601 formatting as standard
trac-0.9.5-ISO8601.patch (2.0 KB ) - added by mark@… 15 years ago.
This is a more advanced patch against version 0.9.5.
trac-0.10.4-ISO8601.patch (4.3 KB ) - added by salrae@… 14 years ago.
version 0.10.4
trac-0.10.4-ISO8601.2.patch (1.1 KB ) - added by salrae@… 14 years ago.
version 0.10.4

Download all attachments as: .zip

Change History (27)

comment:1 by Matthew Good, 16 years ago

Resolution: wontfix
Status: newclosed

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.

comment:2 by chris@…, 16 years ago

Cc: chris@… added
Keywords: ISO 8601 added
Milestone: 1.0
Priority: lowlowest
Resolution: wontfix
Status: closedreopened
Summary: Date Format Inconsistencies (particularly for Milestones)Standardize All Dates On ISO 8601

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

comment:3 by Ian Leader <__ian.leader__@…>, 16 years ago

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)

comment:4 by asmodai@…, 16 years ago


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.

comment:5 by dserodio@…, 16 years ago

Cc: dserodio@… added

comment:6 by Russell Hind <rhind@…>, 16 years ago

Cc: rhind@… added

comment:7 by Matthew Good, 16 years ago

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

comment:8 by mcarpenter@…, 16 years ago

Cc: mcarpenter@… added

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

comment:9 by dave@…, 16 years ago

Cc: dave@… added

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.

comment:10 by anonymous, 16 years ago

how do you do this on solaris?

comment:11 by anonymous, 16 years ago

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?


comment:12 by anonymous, 16 years ago

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

comment:13 by Alec Thomas, 15 years ago

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.

comment:14 by Christian Boos, 15 years ago

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

by anonymous, 15 years ago

ISO 8601 formatting as standard

comment:15 by mark@…, 15 years ago

Priority: lowestnormal
Severity: minornormal

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.

by mark@…, 15 years ago

Attachment: trac-0.9.5-ISO8601.patch added

This is a more advanced patch against version 0.9.5.

comment:16 by Emmanuel Blot, 15 years ago

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

comment:17 by mark@…, 15 years ago

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"?)

comment:18 by Emmanuel Blot, 15 years ago

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"

comment:19 by Matthew Good, 15 years ago

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.

by salrae@…, 14 years ago

Attachment: trac-0.10.4-ISO8601.patch added

version 0.10.4

comment:20 by Christian Boos, 14 years ago

Resolution: duplicate
Status: reopenedclosed

Superseded by #2182.

by salrae@…, 14 years ago

Attachment: trac-0.10.4-ISO8601.2.patch added

version 0.10.4

comment:21 by Christian Boos, 14 years ago

Milestone: 1.0

comment:22 by shuusaku@…, 13 years ago

Cc: shuusaku@… added
Keywords: TIME DATE FORMAT added
Resolution: duplicate
Severity: normalmajor
Status: closedreopened
Summary: Standardize All Dates On ISO 8601Standardize All Dates On ISO 8601 - how can this be done?
Version: devel0.10.4

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

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.

comment:23 by Christian Boos, 13 years ago

Resolution: duplicate
Status: reopenedclosed

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

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.