257146 - Unable to change start and end dates if locale date format is unexpected

Status: RESOLVED INVALID

(Calendar :: General, defect)

Description

[Ambrose Li]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040719 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a3) Gecko/20040812 Mozilla Sunbird/0.2a

The calendar displays start and end dates in the "edit event" dialog in the
locale form, but cannot parse it. Under certain non-English locales (e.g.,
Chinese, Japanese, and Vietnamese locales), the user will be unable to change
start and end dates.

Reproducible: Always
Steps to Reproduce:
1. Run Sunbird in such locales as zh_TW.Big5, ja_JP.eucJP, or vi_VN.UTF-8
2. Bring up the Add event dialog
3. Type a different event Start or End date

Actual Results:  
Upon pressing Ok, the user-specified start or end date immediately reverts to
the original value; the date is not changed.

Expected Results:  
Either

1. The date is changed per the user's specification, or

2. The Start and End date fields uses ISO date format or another parsable
format, so that this problem does not arise.

Comment 1

[gekacheka]

Attachment: dateUtils.patch: allow formats such as 2002Y03M04D as well as 2002-03-04

Interesting.  On Windows, the default short date format is 2002/03/04 in JP so
it parses fine.

I assume the problem on Linux is it is using a format something like
2002Y03M04D (2002年03月04日).  Format code is yyyy'Y'MM'M'dd'D'
(yyyy'年'MM'月'dd'日') Is this assumption correct?

Anyway, this patch fixes parsing for short dates formatted like 2002Y03M04D
(2002年03月04日).

Comment 2

[Mostafa Hosseini]

Checked in.
Thanks

Comment 3

[Ambrose Li]

I don't know how to test the patch (I can't find the .js file). However, looking
at the changes, I don't think this will solve the problem for Chinese and
Vietnamese. Sorry that I was not clear enough in the original report.

The zh_TW.Big5 (Taiwanese convention) long date looks like "CE2002Y03M04D" (西元
2002年03月04日); format code would look like 'CE'yyyy'Y'MM'M'dd'D' ('西元'yyyy'
年'MM'月'dd'日').

The Vietnamese long date looks like "Xxx xxxx 04 Xxx 10 2004". (Sorry, I don't
understand Vietnamese, so I don't know what those X's mean; I just tried a
number of random locales.)

Comment 4

[gekacheka]

(In reply to comment #3)
> I don't know how to test the patch (I can't find the .js file). 

See http://www.mozilla.org/projects/calendar/faq.html#gui_jar

The dateUtils.js file will be at content/calendar/dateUtils.js

> However, looking
> at the changes, I don't think this will solve the problem for Chinese and
> Vietnamese. Sorry that I was not clear enough in the original report.
> 
> The zh_TW.Big5 (Taiwanese convention) long date looks like "CE2002Y03M04D" (西元
> 2002年03月04日); format code would look like 'CE'yyyy'Y'MM'M'dd'D' ('西元'yyyy'
> 年'MM'月'dd'日').
> 
> The Vietnamese long date looks like "Xxx xxxx 04 Xxx 10 2004". (Sorry, I don't
> understand Vietnamese, so I don't know what those X's mean; I just tried a
> number of random locales.)

Calendar's datepicker calls the O.S. for the short date format, not the long
date format.  I can see you might use the chinese format above as the short
format (adds c.e. to distinguish western Common Era year from year in chinese
calendar), but the vietnamese date above looks like a long format.

Comment 5

[Ambrose Li]

(In reply to comment #4)
Indeed the Vietnamese date looks like a long format; I would say even the
Chinese date looks like a long format. Perhaps something more foundational is
broken.

Thanks for the tip on looking for the file. I have tested the patch; indeed it
does not solve the problem in Chinese, but Japanese is ok now.

Comment 6

[gekacheka]

Attachment: dateUtils.js.patch: allow short date such as CE2002Y03M04D for Chinese locale

Also updates comments.	Applies to result of previous patch.

Comment 7

[Mostafa Hosseini]

Second patch checked in. Thanks.
Can this be closed now?

Comment 8

[Ambrose Li]

I hope it won't be closed so soon, my reasoning is:

1. It still doesn't run correctly in Vietnamese locale (which I don't use but have tried during testing)

2. If the Vietnamese string (and I think also the Chinese string) looks like a long format and we're supposed to be using the short format, something foundational seems to be broken on the Linux platform, and we have not identified that thing yet.

I noticed this on my Debian box, so I'll tend to believe it's a real problem with Calendar instead of something wrong with my configuration.

Comment 9

[gekacheka]

Looks like the unix code is using the same format for short and long date format
http://lxr.mozilla.org/mozilla/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#198

Guessing that format is for strptime.
If so, %x is short date, so this could use %Ex for extended/alternative date
http://66.102.7.104/search?q=cache:4KAQaPb6LpwJ:www.uwm.edu/cgi-bin/IMT/wwwman%3Ftopic%3Dstrptime(3)%26msection%3D+strptime+short-date&hl=en

This would fix problem that long date apears same as short date on Unix even if
%Ex format is different.  Is this true?

If this is right, problem of producing locale long date format for %x appears to
be in strptime localization.

Comment 10

[Ambrose Li]

This does not seem to work on all Unix systems.

On my home GNU/Linux x86 system (running glibc 2.2.5), %x produces 2004/08/30
(in zh_TW.Big5 locale), and %Ex produces garbage output (it produces the string
"Ex").

On Debian sid (running glibc 2.3.2 - I tried both x86 and arm), %x and %Ex
produce identical results; both returned the long date format when in the
zh_TW.Big5 locale.

According to MacOSX's strftime man page, %Ex is only "supposed" to provide an
alternate representation :-(

Comment 11

[gekacheka]

Attachment: dateUtils.js.patch: allow non-ASCII prefix, allow long strings between numbers

It turns out the previous patch works for CE2002Y03M04D, but not if non-ASCII
characters are used for the prefix.  This patch fixes that.  It also allows
long non-digit strings between the digits, so may work for the Vietnamese date
format.

Also adds note regarding formats with alphabetic months: Since \w does not
match non-ASCII letters (as required by current JavaScript/EcmaScript
standards), the parser will fail on alphabetic month formats when alphabetic
month contains non-ASCII characters.  Workaround is to use a numeric format.

Comment 12

[Mostafa Hosseini]

Checked in attachment 158641 [details] [diff] [review]. Thanks

Comment 13

[Matthew (lilmatt) Willis]

Reassigning all automatically assigned bugs from Mostafa to nobody@m.o

Bugspam filter: TorontoMostafaMove

Comment 14

[Martin Schröder [:mschroeder]]

Is this bug still valid? There were some checkins in 2004, but I think dateUtils.js isn't used anymore.

Comment 15

[cmtalbert]

Gekachecka, Ambrose, dateUtils has been replaced by calIDateTimeFormatter interface.  This bug now seems invalid.  We are going to close it simply to clear out our listing of old, unconfirmed bugs against the old codebase.  If there are still problems with date formatting, please reopen a bug with those specific problems against the calIDateTimeFormatter component (in bugzilla that would be "Internal Components").

Marking INVALID only because this component is no longer used in the current codebase.

Thanks.