Edgewall Software

Opened 9 years ago

Closed 6 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
Priority: normal Milestone:
Component: general Version: 0.10.4
Cc: chris@…, dserodio@…, rhind@…, mcarpenter@…, dave@…, shuusaku@…
Release Notes:
API 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 8 years ago.
ISO 8601 formatting as standard
trac-0.9.5-ISO8601.patch (2.0 KB) - added by mark@… 8 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@… 7 years ago.
version 0.10.4
trac-0.10.4-ISO8601.2.patch (1.1 KB) - added by salrae@… 7 years ago.
version 0.10.4

Download all attachments as: .zip

Change History (27)

comment:1 Changed 9 years ago by mgood

  • Resolution set to wontfix
  • Status changed from new to closed

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 Changed 9 years ago by chris@…

  • Cc chris@… added
  • Keywords ISO 8601 added
  • Milestone set to 1.0
  • Priority changed from low to lowest
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from Date Format Inconsistencies (particularly for Milestones) to 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 Changed 9 years ago by 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)

comment:4 Changed 9 years ago by asmodai@…

  • Keywords HTTP_ACCEPT_LANGUAGE added

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 Changed 8 years ago by dserodio@…

  • Cc dserodio@… added

comment:6 Changed 8 years ago by Russell Hind <rhind@…>

  • Cc rhind@… added

comment:7 Changed 8 years ago by mgood

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

comment:8 Changed 8 years ago by mcarpenter@…

  • 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 Changed 8 years ago by dave@…

  • 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 Changed 8 years ago by anonymous

how do you do this on solaris?

comment:11 Changed 8 years ago by 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?


comment:12 Changed 8 years ago by anonymous

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

comment:13 Changed 8 years ago by athomas

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 Changed 8 years ago by cboos

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

Changed 8 years ago by anonymous

ISO 8601 formatting as standard

comment:15 Changed 8 years ago by mark@…

  • Priority changed from lowest to normal
  • Severity changed from minor to normal

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.

Changed 8 years ago by mark@…

This is a more advanced patch against version 0.9.5.

comment:16 Changed 8 years ago by eblot

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 Changed 8 years ago by 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"?)

comment:18 Changed 8 years ago by eblot

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 Changed 8 years ago by mgood

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.

Changed 7 years ago by salrae@…

version 0.10.4

comment:20 Changed 7 years ago by cboos

  • Resolution set to duplicate
  • Status changed from reopened to closed

Superseded by #2182.

Changed 7 years ago by salrae@…

version 0.10.4

comment:21 Changed 7 years ago by cboos

  • Milestone 1.0 deleted

comment:22 Changed 6 years ago by shuusaku@…

  • Cc shuusaku@… added
  • Keywords TIME DATE FORMAT added
  • Resolution duplicate deleted
  • Severity changed from normal to major
  • Status changed from closed to reopened
  • Summary changed from Standardize All Dates On ISO 8601 to Standardize All Dates On ISO 8601 - how can this be done?
  • Version changed from devel to 0.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 Changed 6 years ago by cboos

  • Resolution set to duplicate
  • Status changed from reopened to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
as closed The owner will remain jonas.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from jonas to the specified user.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.