Edgewall Software
Modify

Opened 11 years ago

Closed 6 years ago

Last modified 2 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@…
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]

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@… 11 years ago.
The patch resolves this problem.
attachment.2.py (17.8 KB) - added by anonymous 10 years ago.
attachment.py (17.8 KB) - added by takakura 10 years ago.
trac-i18n-datetime.patch (15.0 KB) - added by iizukanao <s03048ni@…> 10 years ago.
Modified trac-patch-2182.diff for use with trac-0.9.6
trac.ini (1.6 KB) - added by anonymous 10 years ago.
trac_iso8601.patch.txt (1.3 KB) - added by follower 7 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 6 years ago.

Download all attachments as: .zip

Change History (104)

comment:1 Changed 11 years ago by dserodio@…

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 Changed 11 years ago by tdkim@…

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 Changed 11 years ago by Christopher Lenz

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 Changed 11 years ago by tdkim@…

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 Changed 11 years ago by Christopher Lenz

(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 Changed 11 years ago by tdkim@…

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

comment:7 Changed 11 years ago by anonymous

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 Changed 11 years ago by markus

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 Changed 11 years ago by tdkim@…

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 Changed 11 years ago by tdkim@…

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 Changed 11 years ago by Christopher Lenz

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 Changed 11 years ago by trac-ja@…

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

Changed 11 years ago by trac-ja@…

Attachment: trac-patch-2182.diff added

The patch resolves this problem.

comment:13 Changed 11 years ago by trac-ja@…

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 Changed 11 years ago by Christopher Lenz

Milestone: 0.9.10.9.2

comment:15 Changed 11 years ago by Matthew Good

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

comment:16 Changed 11 years ago by Christopher Lenz

Milestone: 0.9.31.0

comment:17 Changed 11 years ago by anonymous

Cc: jae+trac@… added

comment:18 Changed 11 years ago by Christopher Lenz

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

Changed 10 years ago by anonymous

Attachment: attachment.2.py added

Changed 10 years ago by takakura

Attachment: attachment.py added

Changed 10 years ago by iizukanao <s03048ni@…>

Attachment: trac-i18n-datetime.patch added

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

comment:19 Changed 10 years ago by iizukanao <s03048ni@…>

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

Cc: tdkim@… added

Changed 10 years ago by anonymous

Attachment: trac.ini added

comment:21 Changed 10 years ago by anonymous

Any updated patch for 0.10.3?

comment:22 Changed 10 years ago by Christian Boos

#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.

comment:23 in reply to:  22 ; Changed 10 years ago by anonymous

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.

comment:24 in reply to:  23 ; Changed 10 years ago by Emmanuel Blot

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.

comment:25 in reply to:  24 ; Changed 10 years ago by anonymous

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

comment:26 in reply to:  25 ; Changed 10 years ago by Emmanuel Blot

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.

comment:27 in reply to:  26 Changed 10 years ago by Emmanuel Blot

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.

comment:28 in reply to:  26 Changed 10 years ago by Christian Boos

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

Cc: manuzhai@… added

comment:30 Changed 9 years ago by techtonik <techtonik@…>

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.

comment:31 in reply to:  30 ; Changed 9 years ago by anonymous

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.

comment:32 in reply to:  31 Changed 9 years ago by Christian Boos

(anonymous was me)

comment:33 Changed 9 years ago by techtonik <techtonik@…>

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 Changed 9 years ago by Christian Boos

Owner: changed from Christopher Lenz to Christian Boos

comment:35 Changed 9 years ago by Christian Boos

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

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

comment:37 Changed 9 years ago by Christian Boos

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

comment:38 Changed 9 years ago by techtonik <techtonik@…>

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 Changed 9 years ago by Christian Boos

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 Changed 9 years ago by Christian Boos

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

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

comment:42 Changed 9 years ago by Christian Boos

Keywords: dateformat added

#5831 was closed as duplicate.

comment:43 Changed 8 years ago by Ivan G Shevchenko

Cc: Shevchenko added

comment:44 Changed 8 years ago by Ivan G Shevchenko <linuxadmin@…>

Cc: linuxadmin@… added

comment:45 Changed 8 years ago by Christian Boos

Milestone: 0.130.12

comment:46 Changed 8 years ago by Christian Boos

#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 Changed 8 years ago by a.a.vykhodtsev@…

Cc: a.a.vykhodtsev@… added

comment:48 Changed 8 years ago by iaindb@…

Cc: iaindb@… added

comment:49 Changed 8 years ago by 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:50 Changed 8 years ago by Everard Brown <everard@…>

Cc: everard@… added

added

comment:51 in reply to:  49 Changed 8 years ago by anonymous

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

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 Changed 7 years ago by Jürgen A. Erhard <jurgen.erhard@…>

Cc: jurgen.erhard@… added

comment:55 Changed 7 years ago by daybreaker12@…

Cc: daybreaker12@… added

comment:56 Changed 7 years ago by anonymous

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 Changed 7 years ago by Erik Andersson <kirean@…>

Cc: kirean@… added

comment:58 Changed 7 years ago by Christian Boos

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

comment:59 in reply to:  52 Changed 7 years ago by Christian Boos

Owner: Christian Boos deleted

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 Changed 7 years ago by Christian Boos

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 Changed 7 years ago by sorin.sbarnea@…

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 Changed 7 years ago by Christian Boos

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

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 Changed 7 years ago by Christian Boos

Milestone: 0.120.12.1

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

comment:65 Changed 7 years ago by Remy Blank

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

comment:66 Changed 7 years ago by n-roeser@…

Cc: n-roeser@… added

Changed 7 years ago by follower

Attachment: trac_iso8601.patch.txt added

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

comment:67 Changed 7 years ago by follower

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 Changed 7 years ago by Christian Boos

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

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.

comment:70 in reply to:  68 Changed 7 years ago by Remy Blank

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 7 years ago by Remy Blank (previous) (diff)

comment:71 Changed 7 years ago by Carsten Klein <carsten.klein@…>

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 Changed 6 years ago by sven@…

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 Changed 6 years ago by hasienda <hoff.st@…>

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.

Changed 6 years ago by Jun Omae

Attachment: i18n-datetime.png added

comment:74 Changed 6 years ago by Jun Omae

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 Changed 6 years ago by hasienda <hoff.st@…>

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.

comment:76 in reply to:  74 ; Changed 6 years ago by Christian Boos

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.

comment:77 in reply to:  76 Changed 6 years ago by Christian Boos

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?

comment:78 in reply to:  76 ; Changed 6 years ago by Jun Omae

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

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

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

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 Changed 6 years ago by Martin Scharrer <martin@…>

Cc: martin@… added

comment:82 in reply to:  78 ; Changed 6 years ago by Christian Boos

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 Changed 6 years ago by hasienda <hoff.st@…>

Cc: hoff.st@… added

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

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 Changed 6 years ago by Christian Boos

Keywords: needfixup added

comment:86 in reply to:  82 Changed 6 years ago by Jun Omae

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 Changed 6 years ago by Christian Boos

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 Changed 6 years ago by Jun Omae

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 Changed 6 years ago by Remy Blank

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!

comment:90 in reply to:  89 Changed 6 years ago by Christian Boos

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.

comment:91 in reply to:  88 ; Changed 6 years ago by Christian Boos

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 ...

comment:92 in reply to:  91 Changed 6 years ago by Jun Omae

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 - 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 Changed 6 years ago by Jun Omae

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

Committed in r10571. Thanks for reviews and suggestions!

comment:94 Changed 6 years ago by Remy Blank

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).

comment:95 in reply to:  94 Changed 6 years ago by Jun Omae

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 Changed 6 years ago by Remy Blank

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 Changed 6 years ago by Remy Blank

Resolution: fixed
Status: reopenedclosed

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

comment:98 Changed 2 years ago by Ryan J Ollos

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.