configurable date and time formats

[tdkim@…]

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.

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

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

[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?

[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…

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

[tdkim@…]

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

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

[markus]

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

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

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

[Christopher Lenz]

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

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

[trac-ja@…]

The patch resolves this problem.

[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

[iizukanao <s03048ni@…>]

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

[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

[anonymous]

Any updated patch for 0.10.3?

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

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

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

[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

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

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

[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:

2007-01-27T19:40 - ISO 8601 01/27/07 07:40 PM - U.S. 27-01-2007 19:40 - Denmark 27/01/2007 19 h 40 - French 2007년 01월 27일 19시 40분 - Korea 2007년 01월 27일 19시 40분 41초 - Korea (+ 초) 01.27.2007 19:40 Uhr - Germany 27/01/2007 19:40 - Ireland 27/01/07 07:40 PM - English 2007年01月27日 19:40 - Japan 27.01.2007 19:40 - Norway

… 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

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

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

[Christian Boos]

(anonymous was me)

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

[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…

[techtonik <techtonik@…>]

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

[Christian Boos]

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

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

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

[Christian Boos]

… 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

[techtonik <techtonik@…>]

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

[Christian Boos]

#5831 was closed as duplicate.

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

[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
  

[Everard Brown <everard@…>]

added

[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
  

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

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

[Christian Boos]

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

[Christian Boos]

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.

[Christian Boos]

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

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

[Christian Boos]

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)

[marti@…]

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

[Christian Boos]

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

[Remy Blank]

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

[follower]

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

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

[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?

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

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

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

[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!

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

[Jun Omae]

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.

• ​http://github.com/jun66j5/trac/blob/t2182-i18n-datetime/trac/util/datefmt.py#L218
• ​http://github.com/jun66j5/trac/blob/t2182-i18n-datetime/trac/util/tests/datefmt.py#L153

If you interest it, please comment. thanks.

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

[Christian Boos]

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

[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?

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

[anonymous]

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

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

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

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

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

[Christian Boos]

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.

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

[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!

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

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

[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 - [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!

[Jun Omae]

Committed in r10571. Thanks for reviews and suggestions!

[Remy Blank]

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

[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

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

[Remy Blank]

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