We've been using jquery/globalize in our web application with the CLDR 29 data in JSON format without any problems. Just recently, Unicode released CLDR 30 (and shortly after, version 30.0.1 with some fixes).
When we upgrade to the CLDR 30(.0.1) data, our client-side currency-formatting tests are failing because, for many cultures, the "currencySpacing" information in numbers.json is no longer there. For example, assuming the culture ar-AE, the Globalize library tries to load CLDR data at the path...
...which doesn't exist in the latest CLDR 30 numbers.json data for this (and many other) cultures.
We've been trying to traverse the stack to see what's causing this problem. We started with the DTD. The DTD for CLDR 30 (along with that for CLDR 29) includes the line...
<!ELEMENT currencyFormats ( alias | ( default*, currencySpacing*, currencyFormatLength*, unitPattern*, special* ) ) >
This was caused by this change: http://unicode.org/cldr/trac/changeset/12636/trunk/common/main/root.xml
Before this change, the root locale's currencySpacing information for the arab number system was inherited by all the other locales. Now it's no longer there.
I'm not sure how the missing currencySpacing should be handled, but the java and C documentation both state that the data can be null. Both appear to use a hard-coded default in that case: http://bugs.icu-project.org/trac/browser/icu4j/trunk/main/classes/core/src/com/ibm/icu/impl/CurrencyData.java#L86
So this is probably a bug in globalize.