As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 543535 - Remove ISO8601DateUtils.jsm
: Remove ISO8601DateUtils.jsm
: addon-compat, dev-doc-needed
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: All All
: -- trivial (vote)
: mozilla8
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 618714 618726 693077
  Show dependency treegraph
Reported: 2010-02-01 12:00 PST by O. Atsushi (Torisugari)
Modified: 2011-12-30 11:56 PST (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

rm (7.83 KB, patch)
2010-12-12 19:26 PST, Phil Ringnalda (:philor)
no flags Details | Diff | Splinter Review
really rm (9.08 KB, patch)
2010-12-12 19:30 PST, Phil Ringnalda (:philor)
no flags Details | Diff | Splinter Review
unrotted (9.14 KB, patch)
2011-08-07 18:42 PDT, Phil Ringnalda (:philor)
gal: review+
Details | Diff | Splinter Review

Description User image O. Atsushi (Torisugari) 2010-02-01 12:00:54 PST
Thanks to bug 430930, now JavaScript Date() can handle ISO-8601. So the browser doesn't need such a library any longer.
Comment 1 User image O. Atsushi (Torisugari) 2010-02-02 07:14:00 PST
I looked into a tree a little, and result:

1. Firefox uses it only within RSS Feed Reader.

1.2. Microformats does not use it, but it has its own ISO8601 bits. Probably this bug won't cover that, but someone some time should fix it (bug 419433 for more details.)

2. Thunderbird also uses it.

3. Others in Gecko family, such as Flock, may be using it.

4. Extension authors? In my opinion, all what this bug can do for them is to remove ISO8601DateUtils.jsm ASAP or mark it as "deprecated" in dev.m.o
Comment 2 User image Phil Ringnalda (:philor) 2010-12-12 19:26:01 PST
Created attachment 497207 [details] [diff] [review]

Too late for 2.0, but I'm pretty confident the patch will elude bitrot until we have a trunk again.
Comment 3 User image Phil Ringnalda (:philor) 2010-12-12 19:30:56 PST
Created attachment 497208 [details] [diff] [review]
really rm

Oops, forgot the part that will bitrot, switching from only removing it ifdef omnijar to always removing it on update/paveover.
Comment 4 User image Phil Ringnalda (:philor) 2011-08-07 18:37:20 PDT
Comment on attachment 497208 [details] [diff] [review]
really rm

In-tree callers are all gone, the only possible even vaguely reasonable consumers would be extensions using the completely untested (and never used in-tree) create(), in which case they can just copy it into their code, and write their own tests for it, since we certainly have no idea whether or not it actually works.
Comment 5 User image Phil Ringnalda (:philor) 2011-08-07 18:42:52 PDT
Created attachment 551369 [details] [diff] [review]

Oh, yeah, guess that rotted a bit over the last eight months.
Comment 6 User image Andreas Gal :gal 2011-08-07 22:00:03 PDT
Are we sure this isn't going to break Thunderbird? And we might want to add a relnote.
Comment 7 User image Andreas Gal :gal 2011-08-07 22:01:09 PDT
Actually, instead we should just make sure we post to the addon community. Looks like really nobody is using this.
Comment 8 User image Jorge Villalobos [:jorgev] 2011-08-08 14:28:31 PDT
The (outdated) add-ons MXR shows 9 hits on AMO. I'll add it to the checks to include the compatibility bump.

I assume this is targeted for Firefox 8?
Comment 9 User image Phil Ringnalda (:philor) 2011-08-08 14:48:10 PDT
It is indeed - I just danced around for an hour about whether I should sit on it for ten days and aim it at 9, but it's such a simple change (if you were using parse, just use the JS Date object, if you were using create... I bet you weren't) that I decided we might as well just do it.
Comment 11 User image Phil Ringnalda (:philor) 2011-08-28 14:35:05 PDT
(In reply to Phil Ringnalda (:philor) from comment #9)
> if you were using create... I bet you weren't

Oh, hello, Date.toISOString().
Comment 12 User image Ben Bucksch (:BenB) 2011-10-14 09:48:10 PDT
Don't EVER remove APIs like that. There was no need to remove this.
ISO dates must be supported. While Date.parse() now supports ISO dates, which is good, there is no standard function to output an ISO date. I need that in pretty much every project, and I don't want to copy&paste that function everywhere.

Removing such basic APIs without replacement is NOT ACCEPTABLE.
Comment 13 User image Phil Ringnalda (:philor) 2011-10-14 10:09:28 PDT
Oh no, you're right! I probably should have said something about the existence of Date.toISOString() in comment 11!
Comment 14 User image Phil Ringnalda (:philor) 2011-10-14 10:10:58 PDT
Comment 15 User image Ben Bucksch (:BenB) 2011-10-14 10:42:38 PDT
I looked at <>, and it doesn't mention toISOString(). It's good that toISOString() is there.

I didn't yell, I used caps for strong emphasis. You yelled. Breaking APIs is no-go, and I want to get that very clear to everybody responsible for breaking APIs.
Comment 16 User image O. Atsushi (Torisugari) 2011-10-15 15:26:18 PDT
(In reply to Ben Bucksch (:BenB) from comment #15)
> I looked at
> <
> jsm>, and it doesn't mention toISOString(). It's good that toISOString() is
> there.

Then, could you update the dev doc?
Comment 17 User image Ben Bucksch (:BenB) 2011-10-15 15:28:55 PDT
Already did
Comment 18 User image O. Atsushi (Torisugari) 2011-10-17 02:33:56 PDT
My bad English writing, by dev-doc I meant

Anyway -> v.
Many thanks to philor and other guys.
Comment 19 User image Ben Bucksch (:BenB) 2011-10-18 08:30:03 PDT
While it is possible to fix extensions by using the new function, modulo the timezone problem, it remains work for extension authors, which would be unnecessary if there was a compat shim that just used the new Date() functions. Those extensions that have not been updated, because the author is not aware, on vacation, whatever, *** will break FF8 entirely ***. On our extension, not even the Firefox Addon page worked anymore, FF was totally broken by the extension, merely due to this lacking import. This is a too high cost. Shipping a 6-line .jsm file is a minor cost in comparison.

Thus, REOPEN, to keep the file, but as a compat shim.
Comment 20 User image Ben Bucksch (:BenB) 2011-10-18 08:32:22 PDT
reassign to gal.
Comment 21 User image Marco Bonardo [::mak] 2011-10-18 08:39:43 PDT
in addons mxr I can find _seven_ add-ons using this old module, maybe it's worth to keep a shim (I don't think so though) but that should be done in a separate regression bug, no point in reopening a bug to do something completely different from its original purpose, neither changing assignee of a fixed bug. That is just going to create confusion.
Comment 22 User image Jorge Villalobos [:jorgev] 2011-10-18 08:58:55 PDT
Filed bug 695345.
Comment 23 User image Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-10-26 09:19:33 PDT
qa- as nothing to do for QA. Please set to qa+ if there is something QA can do to verify this fix.
Comment 24 User image Alex Keybl [:akeybl] 2011-12-04 11:49:58 PST
[Triage Comment]
I've just requested a backout of the removal in bug 695345. We think it's best to add a deprecation warning (in the console) here that would be in a released version for at least 2 releases. Once we've moved past those two releases, we can then move ahead with the removal.

If anybody is interested in speeding up the process, we could uplift the deprecation warning to FF10 (aurora). Please nominate if that's desired.
Comment 25 User image Marco Bonardo [::mak] 2011-12-05 05:48:05 PST
Are we really adding all of this complication for 7 add-ons? While I'm not saying they are not important and I understand the will to not break unless needed, we take a lot of changes that break a far large number of add-ons on a weekly base, and we just notify them on upgrade blogposts, on newsgroups and I suppose we may even notify specific add-ons maintainers. Why is this case so different from the usual?
I think at this point the deprecation warning should absolutely be at least in Aurora.
Comment 26 User image Jorge Villalobos [:jorgev] 2011-12-05 07:02:05 PST
That only covers add-ons on AMO. I was informed about some heavily-used add-ons hosted elsewhere that were going to break because of this, which prompted the reversal and all the extra work. While those add-ons should be fixed by now, I think the deprecation period may still be worthwhile.
Comment 27 User image Marco Bonardo [::mak] 2011-12-05 08:08:35 PST
(In reply to Jorge Villalobos [:jorgev] from comment #26)
> That only covers add-ons on AMO. I was informed about some heavily-used
> add-ons hosted elsewhere that were going to break because of this, which
> prompted the reversal and all the extra work.

Ok, thank you for the clarification, I was not aware of this.
Comment 28 User image Florian Scholz [:fscholz] (MDN) 2011-12-30 11:56:51 PST
Docs no longer say that ISO8601DateUtils.jsm is gone. If so, docs update is needed.

Note You need to log in before you can comment on or make changes to this bug.