Globalize data below available at [https://github.com/jquery/globalize/blob/b13488be2e6ba6603872a41926bd8a08324bfc18/lib/globalize.js], CLDR data below available at [http://unicode.org/Public/cldr/23.1/json.zip]

map - globalize vs CLDR.js

Globalize.cultures[ "default" ] = {

        // -> this is generated
	name: "en",

        // -> main.en.localeDisplayNames.languages.<langName>, eg. langName = "pt-BR"
	englishName: "English",

        // -> main.<langName>.localeDisplayNames.languages.<langName>, eg. langName = "pt-BR"
	nativeName: "English",

        // -> main.<langName>.layout.orientation.characterOrder
	isRTL: false,

	// -> This is generated too
	language: "en",
	
	numberFormat: {
		
		// READ: http://www.unicode.org/reports/tr35/tr35-numbers.html
		pattern: [ "-n" ],
		
		// -> Infer from number pattern?
		decimals: 2,
		
		// -> main.<langName>.numbers.symbols-numberSystem-latn.group
		",": ",",
		
		// -> main.<langName>.numbers.symbols-numberSystem-latn.decimal
		".": ".",
		
		// READ: http://www.unicode.org/reports/tr35/tr35-numbers.html
		groupSizes: [ 3 ],
		
		// -> main.<langName>.numbers.symbols-numberSystem-latn.plusSign
		"+": "+",
		
		// -> main.<langName>.numbers.symbols-numberSystem-latn.minusSign
		"-": "-",
		
		// -> main.<langName>.numbers.symbols-numberSystem-latn.nan
		"NaN": "NaN",
		
		// -> main.<langName>.numbers.symbols-numberSystem-latn.infinity (The symbol ∞, not the text Infinity)
		// OBS: positive vs. negative READ: http://www.unicode.org/reports/tr35/tr35-numbers.html
		negativeInfinity: "-Infinity",
		// symbol used for Positive Infinity
		positiveInfinity: "Infinity",
		
		percent: {
			// READ: http://www.unicode.org/reports/tr35/tr35-numbers.html
			pattern: [ "-n %", "n %" ],
			
			// -> Infer from percentage pattern?
			decimals: 2,
			
			// READ: http://www.unicode.org/reports/tr35/tr35-numbers.html
			groupSizes: [ 3 ],
			
			// -> Does this change compared to normal numbers?? There isn't a single current available culture where this value is different than number's.
			",": ",",
			
			// -> Does this change compared to normal numbers?? There isn't a single current available culture where this value is different than number's.
			".": ".",
			
			// -> main.<langName>.numbers.symbols-numberSystem-latn.percentSign
			symbol: "%"
		},
		currency: {

			// -> main.<langName>.numbers.currencyFormats-numberSystem-latn.standard.currencyFormat.pattern
			// OBS: pattern is a string of the form "<positive>; <negative>". Although, <negative> is not always present.
			pattern: [ "($n)", "$n" ],
			
                        // -> supplemental.currencyData.fractions
			// OBS: there are available the ones different from the default only.
                        // OBS2: they are not based on cultures, but on currencies.
			decimals: 2,
			
			// READ: http://www.unicode.org/reports/tr35/tr35-numbers.html
			groupSizes: [ 3 ],
			
			// -> Does this change compared to normal numbers?? There isn't a single current available culture where this value is different than number's.
			",": ",",
			
			// -> Does this change compared to normal numbers?? There isn't a single current available culture where this value is different than number's.
			".": ".",
			
			// -> This is implemented in a tottaly different way in CLDR. They don't map a currency to a language
			// -> Instead, they have is a list of all the currencies.
			// -> main.<langName>.numbers.currencies.<currencyName>, eg. currencyName = "USD", or "EUR", or "BRL"
			symbol: "$"
		}
	},
	
	calendars: {
		standard: {
			
			// -> CLDR does not say what is the standard calendar of a language.
			// -> Instead it has the locale for 
			name: "Gregorian_USEnglish",
			
			// -> CLDR does not have the separator separated. It's part of the pattern for example dateFormat.
			"/": "/",
			// separator of parts of a time (e.g. ":" in 05:44 PM)
			":": ":",
			
			// -> supplemental.weekData.firstDay
                        // OBS: based per country
			firstDay: 0,

			days: {
				// -> main.<langName>.dates.calendars.gregorian.days.format.wide
				// it's not an array, but an object with {"sun": <sun>, "mon": <mon>, ....}
				names: [ "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" ],
				
				// -> main.<langName>.dates.calendars.gregorian.days.format.abbreviated
				// it's not an array, but an object with {"sun": <sun>, "mon": <mon>, ....}
				namesAbbr: [ "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat" ],
				
				// -> main.<langName>.dates.calendars.gregorian.days.format.short
				// it's not an array, but an object with {"sun": <sun>, "mon": <mon>, ....}
				namesShort: [ "Su", "Mo", "Tu", "We", "Th", "Fr", "Sa" ]
			},
			months: {
				
				// -> main.<langName>.dates.calendars.gregorian.months.format.wide
				// it's not an array, but an object with {1, 2, 3..}
				names: [ "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December", "" ],
				
				// -> main.<langName>.dates.calendars.gregorian.months.format.abbreviated
				// it's not an array, but an object with {1, 2, 3..}
				namesAbbr: [ "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec", "" ]
			},
			
			// -> main.<langName>.dates.calendars.gregorian.dayPeriods.format.abbreviated.am
			// -> there's no standard, lowercase, uppercase differentiation!! Why should it anyway?
			AM: [ "AM", "am", "AM" ],
			
			// -> main.<langName>.dates.calendars.gregorian.dayPeriods.format.abbreviated.pm
			// -> there's no standard, lowercase, uppercase differentiation!! Why should it anyway?
			PM: [ "PM", "pm", "PM" ],
			eras: [				
				{
					// -> main.<langName>.dates.calendars.gregorian.eras.eraAbbr
					"name": "A.D.",
					
					// Perhaps will need to deduce that from:
					// -> supplemental.calendarData.*.eras.*.@start
					"start": null,
					
					// -> Not that simple!
					// -> supplemental.calendarData.*.eras.*.@start
					"offset": 0
				}
			],
			
			// -> MISSING. Isn't this user application level's decision?
			twoDigitYearMax: 2029,
			
			// -> 1st question, shall we map every single pattern below, or we are just going to stick with new CLDR patterns?
			patterns: {

				// -> main.<langName>.dates.calendars.gregorian.dateFormats.short
				// -> although, not identical
				d: "M/d/yyyy",
				
				// -> This long maps to CLDR's full, but note there is CLDR's long too.
				// -> main.<langName>.dates.calendars.gregorian.dateFormats.full, or
				// -> main.<langName>.dates.calendars.gregorian.dateFormats.long
				D: "dddd, MMMM dd, yyyy",
				
				// -> main.<langName>.dates.calendars.gregorian.timeFormats.short
				t: "h:mm tt",
				
				// -> main.<langName>.dates.calendars.gregorian.timeFormats.short
				T: "h:mm:ss tt",
				
				// -> main.<langName>.dates.calendars.gregorian.dateTimeFormats.short:
				// replace {0} with main.<langName>.dates.calendars.gregorian.timeFormats.short
				// replace {1} with main.<langName>.dates.calendars.gregorian.dateFormats.long
				// -> Note, there are others in main.<langName>.dates.calendars.gregorian.dateTimeFormats.availableFormats
				f: "dddd, MMMM dd, yyyy h:mm tt",
				
				// -> main.<langName>.dates.calendars.gregorian.dateTimeFormats.short:
				// replace {0} with main.<langName>.dates.calendars.gregorian.timeFormats.long
				// replace {1} with main.<langName>.dates.calendars.gregorian.dateFormats.long
				F: "dddd, MMMM dd, yyyy h:mm:ss tt",
				
				// month/day pattern
				M: "MMMM dd",
				// month/year pattern
				Y: "yyyy MMMM",
				// S is a sortable format that does not vary by culture
				S: "yyyy\u0027-\u0027MM\u0027-\u0027dd\u0027T\u0027HH\u0027:\u0027mm\u0027:\u0027ss"
			}
		}
	}
};