Created attachment 316221 [details] [diff] [review] Patch rv. 1.0 |ISO8601DateUtils.create| returns |YYYYMMDDThh:mm:ssZ| now. Below is log of xpcshell js> Components.utils.import("resource://gre/modules/ISO8601DateUtils.jsm"); [object BackstagePass] js> ISO8601DateUtils.create(new Date); 20080417T12:15:55Z But |YYYY-MM-DDThh:mm:ssZ| is more common. And its comment says > // YYYY-MM-DDThh:mm:ssZ We should use |YYYY-MM-DDThh:mm:ssZ|
Created attachment 316688 [details] [diff] [review] Yet another patch rv.1. 2008 +0020 +002008 2008-04 2008111 2008-111 20080420 2008W167 2008-W16-7 2008-04-20 2008-04-20T00 200804200000,0 2008-04-20T00Z 2008-04-20T00,0Z 2008-04-20T00+00 2008-04-20T00+00:00 2008-04-20T00:00,0Z 2008-04-20T00:00:00Z 2008-04-20T00:00:00,0Z 2008-04-20T00:00:00.000Z 2008-04-20T00:00:00.000+00:00 2008-04-20T24:00:00Z 2006-01-01T08:59:60+09:00
Created attachment 316740 [details] [diff] [review] Yet another patch rv.2. added some explanations and me as contributors.
drry-san's patch cleans up the entire of ISO8601DateUtils.jsm. # resolves the issue of |create| too. So, I changed the summary and reset the assignee. drry-san, could you accept this bug?
Comment on attachment 316221 [details] [diff] [review] Patch rv. 1.0 obsolete my patch.
Oops! There is no ISO8601.jsm. The right filename is ISO8601DateUtils.jsm :-(
Created attachment 316928 [details] [diff] [review] Yet another patch rv.3. (In reply to comment #4) > drry-san, could you accept this bug? No problem, sir.
Created attachment 316935 [details] [diff] [review] Yet another patch rv.4.
Created attachment 316948 [details] [diff] [review] Yet another patch rv.5.
Created attachment 316978 [details] [diff] [review] Yet another patch rv.6.
Created attachment 317017 [details] [diff] [review] Yet another patch rv.7.
Created attachment 317399 [details] [diff] [review] Yet another patch rv.8. let date = new Date(); let string = ISO8601DateUtils.create(date); print("1: " + string); print("2: " + ISO8601DateUtils.create(date, ISO8601DateUtils.EXTENDED_FORMAT)); print("3: " + ISO8601DateUtils.create(date, ISO8601DateUtils.BASIC_FORMAT)); print("4: " + ISO8601DateUtils.create(date, ISO8601DateUtils.W3CDT_FORMAT | ISO8601DateUtils.AS_LOCAL_TIME)); print("5: " + ISO8601DateUtils.create(date, ISO8601DateUtils.NO_TIMEZONE)); date.setMilliseconds(0); print("6: " + ISO8601DateUtils.create(date)); print("7: " + date); print("8: " + ISO8601DateUtils.parse(string)); date = ISO8601DateUtils.parse("2008-115"); print("9: " + date); print("10: " + date.hasTime); print("11: " + ISO8601DateUtils.create(date)); print("12: " + ISO8601DateUtils.parse("2008W174")); Results: 1: 2008-04-23T22:07:31.827Z 2: 2008-04-23T22:07:31,827Z 3: 20080423T220731,827Z 4: 2008-04-24T07:07:31.827+09:00 5: 2008-04-23T22:07:31,827 6: 2008-04-23T22:07:31Z 7: Thu Apr 24 2008 07:07:31 GMT+0900 8: Thu Apr 24 2008 07:07:31 GMT+0900 9: Thu Apr 24 2008 00:00:00 GMT+0900 10: false 11: 2008-04-23 12: Thu Apr 24 2008 00:00:00 GMT+0900
Created attachment 317478 [details] [diff] [review] Yet another patch rv.9. added two default options |WITH_TIME| and |NO_MILLISECONDS|.
Created attachment 317956 [details] [diff] [review] Yet another patch rv.10. added the leap year and non "minus zero" checking.
Created attachment 319134 [details] [diff] [review] Yet another patch rv.11. Trivial fixes.
Created attachment 325278 [details] Test case for date parsing The patch actually does not do just cleanup; it changes the behavior of the module. Since we need to make sure we don't break the existing behavior, I think we should separate code cleanup (that doesn't affect the behavior) from bug fixes. And indeed there are bugs to be fixed, Bug 439295 for example. Note that this module is used in the feed parser, so if we mess up we can have problems in the dates displayed in the feed preview. I prepared a simple test case for date parsing, so we know how the module is supposed to behave on a few cases. It currently fails because of Bug 439295 (that's the last check). Since you guys seems to know about the ISO8601 date standard better than me feel free to complete/change it, but I think we should at least document any change in the behavior. Some dates are parsed differently with and without the patch (did it became intolerant to the missing "Z" at the end?).
Should be WONTFIX, due to Bug 543535 - Remove ISO8601DateUtils.jsm