trac.ini setting for 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).

[cmlenz]

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

[cmlenz]

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

[cmlenz]

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?

[cboos]

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

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

[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

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

[eblot]

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.

[cboos]

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.

[cboos]

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

[cboos]

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

[cboos]

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.

[cboos]

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

[cboos]

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

[cboos]

#5831 was closed as duplicate.

[cboos]

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

[cboos]

#8323 was closed as duplicate. This is really something that should be fixed for 0.12.

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