Edgewall Software

Opened 12 years ago

Last modified 7 months ago

#10916 new defect

The date/time fields in Custom Query has problem with babel date format. — at Version 2

Reported by: Genie Owned by:
Priority: normal Milestone: next-stable-1.6.x
Component: i18n Version: 1.0
Severity: normal Keywords: babel parse_date format_date
Cc: Jun Omae Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Jun Omae)

Hi~

The date/time fields in Custom Query has problem with babel date format.

The babel date format can contains dot ., and can end with dot ..

2012. 1. 1. babel date format on Korean locale

The date/time fields created and modified in Custom Query can specifying a value containing two dates separated by two dots ...

created=2011-01-01..2012-01-01 query tickets created in 2011 with ISO 8601 format

If we query tickets created in 2011 on Korean locale,

the result of query are fail because three dots ....

created=2011. 1. 1...2012. 1. 1. query tickets created in 2011 with babel date format on Korean

Change History (2)

comment:1 by Christian Boos, 12 years ago

Keywords: babel parse_date format_date added
Milestone: next-stable-1.0.x

Interesting issue!

I'm not sure if you reported it for the TicketQuery macro, the query: TracLinks or the web interface.

For the latter, it seems to work, but there's a little visual glitch. After an update, the values get recomposed as:

<label>between</label>
<input type="text" name="0_time" value="2012. 10. 18" size="14">
<label>and</label>
<input type="text" name="0_time_end" value=".2012. 10. 19." size="14">

A TicketQuery of [[TicketQuery(created=2012. 10. 18...2012. 10. 19.)]] also seems to work, but only as long you have your language set to Korean. So you should rather avoid that unless you're 100% confident all your users have that language setting.

Finally, the query links:

both seem to work if you're using the Korean date format.

… but all of this stops working as soon as you change the language (see e.g. demo-1.0/ticket/967).

So I wonder, if we would allow parse_date to expect any input format:

  • would that even work, or would there be ambiguities?
  • how difficult would that be?

Otherwise, the safest and simplest solution would be to enforce the ISO:6901 format for any date that is likely to be used as part of the content (even in URLs generated by the custom query, although that might be a bit more difficult to achieve).

comment:2 by Jun Omae, 10 years ago

Cc: Jun Omae added
Component: generali18n
Description: modified (diff)
Note: See TracTickets for help on using tickets.