Edgewall Software
Modify

Opened 18 years ago

Closed 13 years ago

Last modified 10 years ago

#2182 closed enhancement (fixed)

configurable date and time formats

Reported by: tdkim@… Owned by: Jun Omae
Priority: high Milestone: 1.0
Component: roadmap Version: devel
Severity: major Keywords: i18n, dateformat, locale, needfixup, preferences
Cc: jae+trac@…, tdkim@…, manuzhai@…, Shevchenko, linuxadmin@…, a.a.vykhodtsev@…, iaindb@…, everard@…, jurgen.erhard@…, daybreaker12@…, kirean@…, marti@…, n-roeser@…, jun66j5@…, martin@…, hoff.st@… Branch:
Release Notes:

Added i18n date and time feature

API Changes:
  • trac.util.datefmt:
    • format_{date,time,datetime}, parse_date and get_{date,datetime}_format_hint takes optionals locale argument (default to None) [10571]
    • Added user_time helper function for format_* and parse_date functions [10571]
  • trac.web.main: Added lc_time property of Request class for selecting the date format [10571]
Internal Changes:

Description

Hi all. Thanks for Trac…

I used Korean date/time format.

This is korean date/time format.
2005년 10월 06일 19시 36분 41초
YYYY년 MM월 DD일 hh시 mm분 ss초

When I enter "10", "11", "12" in month field, Trac shows the error message, "Invalid Date format".

When I enter "010", "011", "012" in month field, There is no error. If I enter "01", … ,"09" in month field, there is no error too.

My Apache config is:

SetHandler mod_python
PythonHandler trac.web.modpython_frontend
PythonOption TracEnv /home/SVN/MYREPO.TRAC
PythonOption TracLocale "ko_KR.utf8"

I tested it in Trac revision 2328 from SVN repo.

Attachments (7)

trac-patch-2182.diff (14.6 KB ) - added by trac-ja@… 18 years ago.
The patch resolves this problem.
attachment.2.py (17.8 KB ) - added by anonymous 18 years ago.
attachment.py (17.8 KB ) - added by takakura 18 years ago.
trac-i18n-datetime.patch (15.0 KB ) - added by iizukanao <s03048ni@…> 18 years ago.
Modified trac-patch-2182.diff for use with trac-0.9.6
trac.ini (1.6 KB ) - added by anonymous 17 years ago.
trac_iso8601.patch.txt (1.3 KB ) - added by follower 14 years ago.
Hacky patch to force dates & times to be formatted as ISO8601 YYYY-MM-DD etc
i18n-datetime.png (20.8 KB ) - added by Jun Omae 14 years ago.

Download all attachments as: .zip

Change History (104)

comment:1 by dserodio@…, 18 years ago

I think that for ModPython what you need is:

SetEnv LC_TIME "ko_KR.utf8"

Anyway, doesn't look like a blocker defect to me.

comment:2 by tdkim@…, 18 years ago

I posted LC_TIME problem using ModPython

http://lists.edgewall.com/archive/trac/2005-September/004846.html

The solution that I found is TracLocale.

I think that this is not ModPython problem. I tested it in CGI mode too.

I think that this problem is blocker, because I can't complete MileStone after Oct(If I don't know that I append '0' to month digits).

comment:3 by Christopher Lenz, 18 years ago

I can't reproduce this here. Have set LC_TIME to ko_KR.utf8 (on Mac OS X 10.4).

However, the date/time format I get is:

YYYY/MM/DD hh시 mm분 ss초
2005/10/18 14시 30분 11초

Apparently, only the time part is using the correct format?

comment:4 by tdkim@…, 18 years ago

Thank you for reply.

To Set LC_TIME is not a solution. I tested LC_TIME, LANG, etc.

Sorry, I can't give you a detail infomation. But I think that the problem exists in a korean environment.

I will try to find a detail infomation. Thanks…

comment:5 by Christopher Lenz, 18 years ago

(I wasn't proposing a solution, I'm just trying to reproduce the problem in the first place, and not succeeding at it.)

comment:6 by tdkim@…, 18 years ago

The problem exists in Timeline too. I think that the problem will exist in all trac components.

comment:7 by anonymous, 18 years ago

I think python's time.strptime just hands off to the C library, so it could be a bug there, in which case it would likely only be reproducible using the same OS as the reporter.

comment:8 by markus, 18 years ago

tdkim, is your Trac install public accessible? If not, can you provide a traceback from trac.log (though I doubt this will help)?

comment:9 by tdkim@…, 18 years ago

This is traceback from trac.log(TracLogging).

14시 21분 07초 Trac[__init__] DEBUG: Promoting anonymous session 7dda7c11b9ec3f4a286fee17 to authenticated session for user fly1004
14시 21분 14초 Trac[__init__] ERROR: 2005년 10월 29일 14시 21분 09초 is not a known date format.
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/modpython_frontend.py", line 206, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/ticket/roadmap.py", line 352, in process_request
    self._do_save(req, db, milestone)
  File "/usr/lib/python2.3/site-packages/trac/ticket/roadmap.py", line 398, in _do_save
    raise TracError(e, 'Invalid Date Format')
TracError: 2005년 10월 29일 14시 21분 09초 is not a known date format.

comment:10 by tdkim@…, 18 years ago

http://bbs.kldp.org/viewtopic.php?t=64252&highlight=milestone

There are some people with the same problem in korean. (The above URL is KLDP(Korea Linux Document Project) bbs.)

His environment is W2000, trac0.8.4( also 0.9b2). He has the same problem and same solution.

comment:11 by Christopher Lenz, 18 years ago

Milestone: 0.90.9.1
Severity: blockermajor

We're gonna need a patch for this one if none of the devs can reproduce the problem. Sorry.

comment:12 by trac-ja@…, 18 years ago

I encount this problem on ‘ja_JP.UTF-8‘.

I tested behaviors of strptime on CentOS-4.2. and I think that probably strptime is not supporting multi-byte charcters.

$ python
>>> from locale import setlocale
>>> from time import strftime, strptime
>>>
>>> setlocale(locale.LC_ALL, 'ja_JP.UTF-8')
'ja_JP.UTF-8'
>>>
>>> text = strftime('%x %X')
>>> text
'2005\xe5\xb9\xb411\xe6\x9c\x8815\xe6\x97\xa5 15\xe6\x99\x8222\xe5\x88\x8624\xe7\xa7\x92'
>>>
>>> strptime(text, '%x %X')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/_strptime.py", line 424, in strptime
    raise ValueError("time data did not match format:  data=%s  fmt=%s" %
ValueError: time data did not match format:  data=2005年11月15日 15時22分24秒  fmt=%x %X
>>>
>>>
>>> text = strftime('%Y-%m-%d %H:%M:%S')
>>> text
'2005-11-15 15:22:53'
>>> strptime(text, '%Y-%m-%d %H:%M:%S')
(2005, 11, 15, 15, 22, 53, 1, 319, -1)
>>>

by trac-ja@…, 18 years ago

Attachment: trac-patch-2182.diff added

The patch resolves this problem.

comment:13 by trac-ja@…, 18 years ago

I wrote a patch that resolves this problem, and attached.

This patch provides enable to configuaring date, time, datetime format in trac.ini. If anyone will use with environmet that LC_TIME contains multibyte charcters, configure to the following.

[i18n]
date_format = %Y-%m-%d
time_format = %H:%M:%S
datetime_format = %Y-%m-%d %H:%M:%S

comment:14 by Christopher Lenz, 18 years ago

Milestone: 0.9.10.9.2

comment:15 by Matthew Good, 18 years ago

Summary: "Invalid Date Format" error in Milestone schedule(Due and completed)trac.ini setting for date and time formats

comment:16 by Christopher Lenz, 18 years ago

Milestone: 0.9.31.0

comment:17 by anonymous, 18 years ago

Cc: jae+trac@… added

comment:18 by Christopher Lenz, 18 years ago

Keywords: i18n added; Invalid Date format removed
Milestone: 1.00.11

by anonymous, 18 years ago

Attachment: attachment.2.py added

by takakura, 18 years ago

Attachment: attachment.py added

by iizukanao <s03048ni@…>, 18 years ago

Attachment: trac-i18n-datetime.patch added

Modified trac-patch-2182.diff for use with trac-0.9.6

comment:19 by iizukanao <s03048ni@…>, 18 years ago

Modified nice trac-patch-2182.diff for use with Trac 0.9.6.
attachment:trac-i18n-datetime.patch

In a trac-0.9.6 source directory, type:

$ patch -p1 < ../trac-i18n-datetime.patch

comment:20 by anonymous, 18 years ago

Cc: tdkim@… added

by anonymous, 17 years ago

Attachment: trac.ini added

comment:21 by anonymous, 17 years ago

Any updated patch for 0.10.3?

comment:22 by Christian Boos, 17 years ago

#4596 was marked as duplicate.

I think that the choice of the datetime format to be used should be part of the Date and Time preference panel, but I'm not exactly sure about how to do it. Should we prepare a list of all the possible choices? Should we let the user compose the format himself?

Suggestions welcomed.

in reply to:  22 ; comment:23 by anonymous, 17 years ago

Replying to cboos:

Should we prepare a list of all the possible choices? Should we let the user compose the format himself?

A mixture of both would be cool. For example, set of very common formats (short, long) could be compiled and optional the user should be allowed to specify a custom one.

in reply to:  23 ; comment:24 by Emmanuel Blot, 17 years ago

Replying to anonymous:

the user should be allowed to specify a custom one.

I think we should implement this only if we are able to come with a clean and lean interface. This could be hard to achieve w/ a web interface.

in reply to:  24 ; comment:25 by anonymous, 17 years ago

Replying to eblot:

Replying to anonymous:

the user should be allowed to specify a custom one.

I think we should implement this only if we are able to come with a clean and lean interface. This could be hard to achieve w/ a web interface.

Mhm. Hard to achieve? In WordPress it's a simple text field where the user enters the pattern that is passed to the date function.

http://en.wikipedia.org/wiki/KISS_principle

in reply to:  25 ; comment:26 by Emmanuel Blot, 17 years ago

Replying to anonymous:

Mhm. Hard to achieve? In WordPress it's a simple text field where the user enters the pattern that is passed to the date function.

Exactly: to me, this is the exact opposite of a clean and lean interface: asking the end user to enter text keywords to set up his UI preferences.

in reply to:  26 comment:27 by Emmanuel Blot, 17 years ago

Replying to eblot:

asking the end user to enter text keywords to set up his UI preferences.

IMHO, the "text keywords" stuff is similar the to 'Report' feature (where we need to deal w/ SQL requests) while I would expect an interface similar to the "custom query" one, with simple drop-down list items.

in reply to:  26 comment:28 by Christian Boos, 17 years ago

Replying to eblot:

Replying to anonymous:

Mhm. Hard to achieve? In WordPress it's a simple text field where the user enters the pattern that is passed to the date function.

Exactly: to me, this is the exact opposite of a clean and lean interface: asking the end user to enter text keywords to set up his UI preferences.

Entering additional patterns for the date and time format could be done by the administrator, by editing the TracIni

[datetime]
Korea (+ 초) = %Y년 %M월 %d일 %H시 %M분 %S초

And that would show up (as 2007년 01월 27일 19시 40분 41초 - Korea (+ 초) in a drop-down list, in addition to a few well known ones:

… and the user would only have to select one from the list.

That list has been quickly compiled from Wikipedia, so any correction/enhancement is welcomed, of course.

References: Wikipedia:Calendar_date and Wikipedia:Date_and_time_notation_by_country

comment:29 by Manuzhai <manuzhai@…>, 17 years ago

Cc: manuzhai@… added

comment:30 by techtonik <techtonik@…>, 17 years ago

Dropdown box above is awful. It is better to use simple text field in admin interface, which will contain format string stored in trac.ini There should be a link to Trac wiki page with reference about pattern syntax description and table of common formats.

Remember that Trac is itself not an easy system to install for ordinary user and it makes little sense wasting time for implementing feature for trac "admins" who are unable to understand standard date pattern from reference.

in reply to:  30 ; comment:31 by anonymous, 17 years ago

Replying to techtonik <techtonik@gmail.com>:

Dropdown box above is awful.

Ok, putting an example date within the dropdown itself was not a bright idea (well, at least as one can have that left aligned and the name right aligned), so it's better to have only a list of names and show how it will look like after update (similar to the selection of the time zone).

What you seem to have missed is that this will be a user preference, not a system wide setup. The admin would eventually be able to add more choices and a system default. This will be setup in the trac.ini.

in reply to:  31 comment:32 by Christian Boos, 17 years ago

(anonymous was me)

comment:33 by techtonik <techtonik@…>, 17 years ago

I think it is too complicated with names and drop-down boxes. I doubt that this option will be popular at all if Trac chooses something more intuitive than US mm/dd/yyyy format, e.g. yyyy-mm-dd

I never use the date of my locale. What I need is to avoid the users being confused. If I set up the most intuitive format like yyyy-mm-dd - I bet nobody will complain to change the date even if dd-mm-yyyy is more familiar here, but I do not know if it is a format of my native locale or not.

So I think that for 0.11 a date format specifier is a must, but let it be simple. In any case if there will be an option on this site - you can calculate how many users will actually use it.

comment:34 by Christian Boos, 17 years ago

Owner: changed from Christopher Lenz to Christian Boos

comment:35 by Christian Boos, 17 years ago

#5345 marked as duplicate, and states quite concisely the need for having user specific setting:

If a distributed team working on the project it is beneficial to have correct date/time format for everybody. Site-global settings described in the documentation are not appropriate. E.g. some developers working in US, some in Europe…

comment:36 by techtonik <techtonik@…>, 17 years ago

I wonder if #5345 could arise if Trac used ISO date format. Have site-wide admin settings is a necessary minimum.

comment:37 by Christian Boos, 17 years ago

How widespread is the adoption of ISO:8601 in the US for example?

comment:38 by techtonik <techtonik@…>, 17 years ago

The problem is caused not by absence of ISO, but by confusion of U.S. mm/dd/yyyy with dd/mm/yyyy in other countries. It is impossible to say which format is used in date like 12/03/2004 without looking anywhere else. On the other side ISO removes this ambiguity.

comment:39 by Christian Boos, 17 years ago

Well, I perfectly agree about adopting ISO as a "sane" default setting. We should at the very least implement that for 0.11.

comment:40 by Christian Boos, 17 years ago

Milestone: 0.11.10.12

… or 0.11.1 ;-)

But for the main feature discussed here, it probably makes sense to wait until we use Babel, i.e. 0.12.

See babel:Documentation/dates.html

comment:41 by techtonik <techtonik@…>, 17 years ago

Should we split this one in two - "separate trac-wide date setting with default ISO format" and "personalized date settings"?

comment:42 by Christian Boos, 16 years ago

Keywords: dateformat added

#5831 was closed as duplicate.

comment:43 by Ivan G Shevchenko, 16 years ago

Cc: Shevchenko added

comment:44 by Ivan G Shevchenko <linuxadmin@…>, 16 years ago

Cc: linuxadmin@… added

comment:45 by Christian Boos, 16 years ago

Milestone: 0.130.12

comment:46 by Christian Boos, 16 years ago

#1690 closed as duplicate.

Besides locale related formats, it should be possible to choose ISO 8601 format.

While using Babel for some date format related stuff might be nice, I don't think we should rely on it. Instead, we should do something similar as we did for the datetime switch and pytz: have our own minimal implementation and allow the use of a more comprehensive (but optional) external dependency.

comment:47 by a.a.vykhodtsev@…, 16 years ago

Cc: a.a.vykhodtsev@… added

comment:48 by iaindb@…, 16 years ago

Cc: iaindb@… added

comment:49 by Everard Brown <everard@…>, 16 years ago

Wouldn't it be nice for the date-time to be displayed in the format derived from the locale of the browser.

i.e. If the viewer is using:

  • en-US they see 01/02/02
  • en-GB they see 02/01/02
  • de-DE they see 02.01.2002
  • etc.
  • If the browser locale can not be determined, then use ISO 8601

comment:50 by Everard Brown <everard@…>, 16 years ago

Cc: everard@… added

added

in reply to:  49 comment:51 by anonymous, 15 years ago

no, not at all! how can one set then the international standards, "en" as language, and iso as date format?

Replying to Everard Brown <everard@…>:

Wouldn't it be nice for the date-time to be displayed in the format derived from the locale of the browser.

i.e. If the viewer is using:

  • en-US they see 01/02/02
  • en-GB they see 02/01/02
  • de-DE they see 02.01.2002
  • etc.
  • If the browser locale can not be determined, then use ISO 8601

comment:52 by srevill@…, 15 years ago

Bump.

Is there any chance of someone fixing this - sounds pretty trivial to me. The fact this has sat here festering for six months makes me feel like learning Python myself.

comment:53 by Jürgen A. Erhard <jurgen.erhard@…>, 15 years ago

Cc: jurgen.erhard@… added

comment:55 by daybreaker12@…, 15 years ago

Cc: daybreaker12@… added

comment:56 by anonymous, 15 years ago

This is exactly why in all our docs we use the format DD MMM YYYY : 04 May 2009

No matter what country you're in, you don't screw it up. Well assuming you can read, are on the same calendar system as the rest of the world, and know the (in this case) english 3 letter for the months. but you get the idea. A format string would be nice. additionally, a short-form string should be considered, and also if you want the short-form/long form on hover type behavior in tickets/timeline etc., or to force long form everywhere. etc.

comment:57 by Erik Andersson <kirean@…>, 15 years ago

Cc: kirean@… added

comment:58 by Christian Boos, 15 years ago

There was a similar issue with the Bulgarian date format (#8136).

in reply to:  52 comment:59 by Christian Boos, 14 years ago

Owner: Christian Boos removed

Replying to srevill@…:

… makes me feel like learning Python myself.

So, I suppose 8 months was plenty enough to learn Python ;-)

I'd like to see a solution based on my comments comment:22, comment:31, and comment:46. I don't think I'll be able to do it for 0.12, though.

comment:60 by Christian Boos, 14 years ago

Keywords: locale added

Being able to change the date format without having to set the locale would also enable us to remove the setlocale call, and avoid the various hard to troubleshoot problems related to setlocale (see #6953, #7686, #2971 and now ticket:8544#comment:2).

comment:61 by sorin.sbarnea@…, 14 years ago

I would like to know why a simple bug like this, having a patch is opened for more than 4 years. I think it was good enough to be able to configure the date format for the trac server would be an acceptable solution. Also the default must be ISO 8601.

Now having the dates in ISO 8601 is big bug that should be solved ASAP. Being able to customize the dates is a enhancement that can wait for while.

comment:62 by Christian Boos, 14 years ago

Summary: trac.ini setting for date and time formatsconfigurable date and time formats

To sum up this issue:

  • date and time formats should not be set via setlocale (comment:60), support for ISO:8601 can't be obtained that way anyway
  • trac.ini setting for the default
  • ideally, make it a user preferences, like the time zone (on the same Date & Time panel) (comment:28, but the "example" formatted date and time should be the one already in the panel, not within the select input)

comment:63 by marti@…, 14 years ago

Cc: marti@… added

(I have to type something here to add myself to the "Cc:" because otherwise Trac will think my comment is spam. Annoying, please fix this!)

comment:64 by Christian Boos, 14 years ago

Milestone: 0.120.12.1

Not absolutely critical for 0.12, contributions welcomed (see comment:62 for a summary).

comment:65 by Remy Blank, 14 years ago

#8945 asks for a user-specific timezone in notification e-mails.

comment:66 by n-roeser@…, 14 years ago

Cc: n-roeser@… added

by follower, 14 years ago

Attachment: trac_iso8601.patch.txt added

Hacky patch to force dates & times to be formatted as ISO8601 YYYY-MM-DD etc

comment:67 by follower, 14 years ago

I just added a patch trac_iso8601.patch.txt that forces all dates and times to be formatted as ISO8601 style.

It seems date formatting has all been moved into datefmt.py since the previous patches on this issue were created. This suggests that adding a configurable default format would be a lot easier now.

Instead of harcoding "iso8601" as I do in this patch it could be changed to read a value from trac.ini instead.

In the interim this patch will hopefully help those like me who just want an international format. :)

comment:68 by Christian Boos, 14 years ago

Thanks for looking into this. I wonder if it wouldn't make sense to apply the patch while waiting for the "full solution". ISO:8601 format seems to be a much better default than whatever locale is set for the server.

Opinions?

comment:69 by todor@…, 14 years ago

For me "Timeline" and some of the "Administration" interface is totally broken, so I'd be very happy to have this patch committed in the official release.

in reply to:  68 comment:70 by Remy Blank, 14 years ago

Replying to cboos:

I wonder if it wouldn't make sense to apply the patch while waiting for the "full solution". ISO:8601 format seems to be a much better default than whatever locale is set for the server.

I have switched my servers to ISO-8601 a long time ago, so personally I wouldn't mind. But this would leave no possibility to change it back to something else (whereas currently, it can be done by changing the locale). Maybe better leave it as-is until it can at least be configured cleanly server-wide.

Last edited 14 years ago by Remy Blank (previous) (diff)

comment:71 by Carsten Klein <carsten.klein@…>, 14 years ago

in order to solve this, why not restrict the user to an input format that is defined by the server?

and by that, also, make it configurable in the trac.ini configuration.

additionally, do not let users enter dates manually but use a javascript extension that will provide a calendar/date/datetime chooser, which will set up the form fields in the appropriate format, only.

comment:72 by sven@…, 14 years ago

I just created a new ticket #9246 that happened to be a duplicate of this one. Just for the records - I vote for standards (ISO and others). I also vote for 4-digit year numbers. 10!=2010!

comment:73 by hasienda <hoff.st@…>, 14 years ago

I'm working hard towards custom time field support for Trac trunk (0.13?). I invite you to have a look at the work in progress including proposal for implementation. I took the date/time format from locale too, but any hint apart from the discussion here will help me to improve the available options for format customization, as is requested for code in Trac trunk here.

I offer not only another open ear. With some support (suggestions, code, testing) I might be able to make a reference implementation for the custom time fields and extend it to all time fields later. Any work is available within but not tied to the custom time fields approach. So if you'll help me, you'll get a dedicated patch against Trac trunk, that will be maintained inside my Mercurial Queue at bitbucket.org. I guess this would not only help custom time fields effort but in the first place could lead to a consistent date/time format solution for all time fields.

BTW, the date-picker is on my ToDo too.

by Jun Omae, 14 years ago

Attachment: i18n-datetime.png added

comment:74 by Jun Omae, 14 years ago

Cc: jun66j5@… added

Hi,

I think it should do i18n using babel.dates.format_* methods and the locale is taken from user's preference or browser's language. (not trac.ini)

I worked for the issue using babel - http://github.com/jun66j5/trac/tree/t2182-i18n-datetime.

The patch creates new i18n date methods.

  • format: i18n_format_datetime, i18n_format_date and 18n_format_time
  • hint: i18n_get_date_format_hint and i18n_get_datetime_format_hint
  • parse: i18n_parse_date

It is alpha status, however includes the unit tests.

If you interest it, please comment. thanks.

comment:75 by hasienda <hoff.st@…>, 14 years ago

Interested? Of course I am. Moving Trac locale setting from server to clients is most useful with the date/time presentation. I'll definitely follow, review and test this. Thanks for the effort in pushing the subject.

in reply to:  74 ; comment:76 by Christian Boos, 14 years ago

Milestone: 0.12.10.13
Owner: set to Jun Omae
Type: defectenhancement

(Requalifying as enhancement, and as such moving to 0.13)

Replying to jomae:

I think it should do i18n using babel.dates.format_* methods and the locale is taken from user's preference or browser's language. (not trac.ini)

It would be nice if in addition the user could explicitly select the IS0 format (#1690). This would imply using another selector than req.locale, for example a new req.session['lc_time'] if the user has set that key. Maybe a helper function would be useful, something like user_time(req, format_datetime, *args).

I worked for the issue using babel - http://github.com/jun66j5/trac/tree/t2182-i18n-datetime.

Great!

The patch creates new i18n date methods.

  • format: i18n_format_datetime, i18n_format_date and 18n_format_time
  • hint: i18n_get_date_format_hint and i18n_get_datetime_format_hint
  • parse: i18n_parse_date

Is this really needed? Couldn't we just use the existing names for these functions, as you've put the extra locale=None at the end anyway? The former methods could be renamed to _format_... and as they get used when leaving the locale argument unspecified, we keep full backward compatible behavior.

Otherwise, looks quite good. I suppose having some minimal functionality also without Babel would be too bothersome, so let's make that a Babel only feature, that's already better than no feature at all ;-) Except for the support for iso formats, it should be possible to have those even without Babel.

in reply to:  76 comment:77 by Christian Boos, 14 years ago

I worked for the issue using babel - http://github.com/jun66j5/trac/tree/t2182-i18n-datetime.

Great!

Looking closer, your repo doesn't seem to share the same history as our mirror, how did you proceed?

in reply to:  76 ; comment:78 by Jun Omae, 14 years ago

Replying to cboos:

I think it should do i18n using babel.dates.format_* methods and the locale is taken from user's preference or browser's language. (not trac.ini)

It would be nice if in addition the user could explicitly select the IS0 format (#1690). This would imply using another selector than req.locale, for example a new req.session['lc_time'] if the user has set that key. Maybe a helper function would be useful, something like user_time(req, format_datetime, *args).

req.session['lc_time']! Great idea!

The patch creates new i18n date methods.

  • format: i18n_format_datetime, i18n_format_date and 18n_format_time
  • hint: i18n_get_date_format_hint and i18n_get_datetime_format_hint
  • parse: i18n_parse_date

Is this really needed? Couldn't we just use the existing names for these functions, as you've put the extra locale=None at the end anyway? The former methods could be renamed to _format_... and as they get used when leaving the locale argument unspecified, we keep full backward compatible behavior.

I agreed about the locale argument.

The reason is…

The format argument of format_datetime expects %Y-%m-d, %H:%M, etc. like strftime, however babel.dates.format_datetime expects medium, short, yyyy.MM.dd G 'at' HH:mm:ss zzz, etc.. Two formats are incompatible.

cf. babel:wiki:ApiDocs/0.9/babel.dates#babel.dates:format_datetime

Do you have good idea?

Replying to cboos:

I worked for the issue using babel - http://github.com/jun66j5/trac/tree/t2182-i18n-datetime.

Great!

Looking closer, your repo doesn't seem to share the same history as our mirror, how did you proceed?

Sorry. I've mistaken….

  1. git svn clone http://svn.edgewall.org/repos/trac/trunk (first mistake)
  2. git checkout -b t2182-i18n-datetime
  3. work for the issue
  4. fork on github
  5. git remote add myfork git@github.com:jun66j5/trac.git
  6. git push myfork t2182-i18n-datetime

I will create it later again.

Thanks.

comment:79 by anonymous, 14 years ago

hi i want to change date to display dd/mm/yyyy since it is in mm/dd/yyyy by default in rhel5

in reply to:  76 ; comment:80 by Martin Scharrer <martin@…>, 14 years ago

Replying to cboos:

Replying to jomae:

The patch creates new i18n date methods.

Is this really needed? Couldn't we just use the existing names for these functions, as you've put the extra locale=None at the end anyway? The former methods could be renamed to _format_... and as they get used when leaving the locale argument unspecified, we keep full backward compatible behavior.

Otherwise, looks quite good. I suppose having some minimal functionality also without Babel would be too bothersome, so let's make that a Babel only feature, that's already better than no feature at all

Just came here to open exactly this ticket. Good thing I was searching first :-)

I would also vote to add a 'locale=None' argument to Tracs 'format_datetime' to make the argument list compatible to Babels version. The first argument 't' (trac) or 'datetime' (babel) should also made identical, just to be safe. The Trac function could then simply call the Babel function if Babel is installed or fall back to the current implementation, which uses the servers locale I think.

I just implemented something like this in th:changeset:8775 for the th:WatchlistPlugin which is currently localised to German:

try: 
    from  babel.dates        import  format_datetime 
except ImportError: 
    from  trac.util.datefmt  import  format_datetime as _format_datetime 
    def format_datetime(t=None, format='%x %X', tzinfo=None, locale=None): 
 	return _format_datetime(t, format, tzinfo) 

Even if you only add a 'locale=None' argument and ignore it plug-in developer could simply write:

try: 
    from  babel.dates        import  format_datetime 
except ImportError: 
    from  trac.util.datefmt  import  format_datetime

A good enhancement in my humble opinion.

comment:81 by Martin Scharrer <martin@…>, 14 years ago

Cc: martin@… added

in reply to:  78 ; comment:82 by Christian Boos, 14 years ago

And also:

Replying to jomae:

Replying to cboos:

… Couldn't we just use the existing names for these functions,

I agreed about the locale argument.

The reason is…

The format argument of format_datetime expects %Y-%m-d, %H:%M, etc. like strftime, however babel.dates.format_datetime expects medium, short, yyyy.MM.dd G 'at' HH:mm:ss zzz, etc.. Two formats are incompatible.

cf. babel:wiki:ApiDocs/0.9/babel.dates#babel.dates:format_datetime

Do you have good idea?

I see that in e5abd67d, you convert the given Babel formats to those supported by the current format_ functions. That should be enough, and we're in a major release, so the API can evolve…

I'd suggest having something like:

def format_datetime(datetime=None, format=None, tzinfo=None, locale=None):
    """Format the `datetime` object `datetime` into an `unicode` string

    If `datetime` is None, the current time will be used.

    The formatting will be done using the given `format`, which consist
    of conventional `strftime` keys. In addition the format can be 'iso8601'
    to specify the international date format (compliant with RFC 3339).
    If `format` is None, the ISO 8601 format will be used.
    
    `tzinfo` will default to the local timezone if left to `None`.

    `locale` specifies how the format should be localized, if Babel
    is present.
    """

comment:83 by hasienda <hoff.st@…>, 14 years ago

Cc: hoff.st@… added

in reply to:  80 comment:84 by Martin Scharrer <martin@…>, 14 years ago

Replying to Martin Scharrer <martin@…>:

Even if you only add a 'locale=None' argument and ignore it plug-in developer could simply write:

Just figured that is not true in all cases. Babels format_datetime doesn't take format='iso8601', at least not correctly. To format timeline links Tracs version must be used. Would be great to get the function suggested in comment:82. I would help coding it if needed.

comment:85 by Christian Boos, 13 years ago

Keywords: needfixup added

in reply to:  82 comment:86 by Jun Omae, 13 years ago

Replying to cboos:

I see that in e5abd67d, you convert the given Babel formats to those supported by the current format_ functions. That should be enough, and we're in a major release, so the API can evolve…

I'd suggest having something like:

def format_datetime(datetime=None, format=None, tzinfo=None, locale=None):
....

Thanks for your comments.

Ok, I will rework the issue and my patch…

  1. Add to the locale argument to format_datetime, format_time, get_datetime_format_hint and parse_date and remove i18n_* methods from my patch.
  2. Merge i18n datetime feature to trac.util.datefmt.* methods.
  3. Add a helper function like user_time(req, format_datetime, *args).
  4. Add trac.ini setting for the default datetime format like [trac] default_language. Users can specify a locale, iso8601.
  5. Add new prefs panel for user's datetime format. (default is in trac.ini)

comment:87 by Christian Boos, 13 years ago

Keywords: userpreferences added

For 3. and 4. (user_time and default_date_format) this is also a use case for the new User Preferences for options (see beginning of proposals in ticket:3360#comment:4 and ticket:6002#comment:5).

Note that this is not necessarily a prerequisite for this ticket, I just wanted to hint about the future directions.

comment:88 by Jun Omae, 13 years ago

I fixed up my patch in comment:68, now. I want to release the feature in 0.13.

I have tested unit and functional tests with Python 2.5-2.7 on Linux/i386 and Windows XP.

https://github.com/jun66j5/trac/tree/t2182-i18n-datetime (compare with trunk)

comment:89 by Remy Blank, 13 years ago

That's an impressive piece of work, Jun! I have quickly read through the diff, and it "reads" very well. I would also very much like to see this in 0.13, so keep pushing!

in reply to:  89 comment:90 by Christian Boos, 13 years ago

Replying to rblank:

That's an impressive piece of work, Jun! I have quickly read through the diff, and it "reads" very well. I would also very much like to see this in 0.13, so keep pushing!

Same here ;-) I'm currently going through, only found good things so far (in particular how you managed to have user_time also take care of the parsing, great!).

I think given the size of the patch, you should give us a few days so that we can test it in some depth, and once we feel confident and familiar enough with the changes (in such a way we could quickly fix glitches by ourselves should they happen), you will be able to apply it.

in reply to:  88 ; comment:91 by Christian Boos, 13 years ago

Reviewing:

https://github.com/jun66j5/trac/compare/trunk...t2182-i18n-datetime

I read the patch in more details, and I have the following suggestions for improvements:

trac/prefs/templates/prefs_datetime.html
no need for i18n:msg attribute as it's already a complete sentence not broken up by sub-elements.
trac/ticket/roadmap.py
whenever you change something written as A and B or C, please replace with the safer Python 2.5 construct B if A else C
trac/util/datefmt.py
  • isinstance(t, datetime) you use astimezone + evt. normalize, but what about using localize as we do below for isinstance(t, date)? But maybe I miss something, like why it was not initially done that way in r8831
  • in format_datetime() and friends, the test babel is not None and locale is not None is a bit verbose, maybe we could use the reverse condition which can be written more compactly: babel is locale is None ;-)
  • in parse_date(), .get(hint, lambda: hint)(locale) will eventually fail
  • in user_time() doc string: "It expects using with …" ⇒ "It is expected to be used with …" (+ twice "arugment" typo)
trac/web/main.py
  • default_date_format: """The preference date format to use if no user preference has been set""" ⇒ simply "The date format …"
  • in _get_lc_time(), self.default_date_format is not ultra-cheap, so just call it when needed
trac/wiki/tests/formatter.py
another ... and ... or ...

in reply to:  91 comment:92 by Jun Omae, 13 years ago

Replying to cboos:

trac/util/datefmt.py
  • isinstance(t, datetime) you use astimezone + evt. normalize, but what about using localize as we do below for isinstance(t, date)? But maybe I miss something, like why it was not initially done that way in r8831

The localize method raises ValueError if t.tzinfo is already set. cf - trunk/trac/util/datefmt.py@10424:357-358#L356.

In this case, we need convert t to tzinfo timezone from the original timezone. And this code is the same one of format_datetime and format_time in babel.dates.

However, babel's format_time has one problem that uses normalize method without confirming getattr(tz, 'normalize', None'), So we must convert its timezone by itself. cf - [babel:source:tags/0.9.5/babel/dates.py@:581-582#L578].

I understand and agree the other suggestions. I will fix until tomorrow. Thanks!

comment:93 by Jun Omae, 13 years ago

API Changes: modified (diff)
Release Notes: modified (diff)
Resolution: fixed
Status: newclosed

Committed in r10571. Thanks for reviews and suggestions!

comment:94 by Remy Blank, 13 years ago

Resolution: fixed
Status: closedreopened

I get a few test failures since [10571]:

======================================================================
FAIL: Admin milestone completed
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/joe/src/trac/trunk/trac/ticket/tests/functional.py", line 442, in runTest
    tc.url(milestone_url + "$")
  File "/usr/lib/python2.6/site-packages/twill/commands.py", line 178, in url
    """ % (current_url, should_be,))
TwillAssertionError: current url is 'http://127.0.0.1:8054/admin/ticket/milestones/CompletedMilestone';
does not match 'http://127.0.0.1:8054/admin/ticket/milestones$'

======================================================================
FAIL: Admin milestone duedate
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/joe/src/trac/trunk/trac/ticket/tests/functional.py", line 406, in runTest
    tc.find(duedate_string)
  File "/home/joe/src/trac/trunk/trac/tests/functional/better_twill.py", line 189, in better_find
    raise twill.errors.TwillAssertionError(*args)
TwillAssertionError: (u"no match to 'Feb 22, 2011 12:06:19 AM'", '/home/joe/src/trac/trunk/testenv/trac/log/TestAdminMilestoneDue.html')

======================================================================
FAIL: Admin modify milestone duedate on detail page
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/joe/src/trac/trunk/trac/ticket/tests/functional.py", line 427, in runTest
    tc.find(name + '(<[^>]*>|\\s)*'+ duedate_string, 's')
  File "/home/joe/src/trac/trunk/trac/tests/functional/better_twill.py", line 189, in better_find
    raise twill.errors.TwillAssertionError(*args)
TwillAssertionError: (u"no match to 'DetailDueMilestone(<[^>]*>|\\s)*Feb 22, 2011 12:06:20 AM'", '/home/joe/src/trac/trunk/testenv/trac/log/TestAdminMilestoneDetailDue.html')

======================================================================
FAIL: test_format_compatibility (trac.util.tests.datefmt.I18nDateFormatTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/joe/src/trac/trunk/trac/util/tests/datefmt.py", line 475, in test_format_compatibility
    datefmt.format_datetime(t, 'medium', tz))
AssertionError: '08/28/10 13:45:56' != u'2010-08-28 13:45:56'

The first one happens only between 00:00 and 01:00 my time (I'm on GMT+01:00), and is due to an error generated when completing a milestone in the admin panel, saying that the completion time cannot be in the future. This sounds familiar, so maybe it's a regression.

The second and third have a pattern that looks for "12:06:19 AM" when it's actually "12:06:19 PM" here. I assume it only happens between 00:00 and 01:00 UTC.

The fourth one is weird: it only happens if I run both the unit tests and functional tests in the same run, i.e. with:

python trac/test.py

If I run only the unit tests, it passes. Maybe the functional tests somehow change the locale (the actual value in the assertion corresponds to the time format for my locale).

in reply to:  94 comment:95 by Jun Omae, 13 years ago

Oh…, it's so bad. I have created the bug in parse_date with AM/PM marker and failure tests with non C locale.

Fixed in r10583 and tested with Python 2.5, 2.6 and 2.7 on Linux and Windows.

$ for i in C en_US.UTF-8 fr_FR.UTF-8 ja_JP.UTF-8; do LANG=$i PYTHONPATH=$PWD python trac/test.py; done

comment:96 by Remy Blank, 13 years ago

Great, all tests pass now, so at least the fourth failure from comment:94 is gone. I'll wait for tonight to check the other ones :)

comment:97 by Remy Blank, 13 years ago

Resolution: fixed
Status: reopenedclosed

All tests still pass shortly before and shortly after 01:00 my time. Thanks Jun!

comment:98 by Ryan J Ollos, 10 years ago

Keywords: preferences added; userpreferences removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jun Omae.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jun Omae 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.