The initWithString: method previously initialized the underlying JavaScript Date object using the local-time constructor (new Date(year, month, day)).
This caused the resulting absolute time to be corrupted by the host engine's local time zone configuration, effectively ignoring the explicit time zone offset provided in the initialization string.
The implementation was a fundamental violation of the canonical contract, as established by NSDate and to be followed by CPDate.
This commit refactors the parsing logic to use Date.UTC(), guaranteeing that the parsed components are evaluated independently of the host environment.
Additionally, it eliminates a redundant RegExp allocation during pattern matching and updates the API documentation to explicitly state that offset resolution is decoupled from both CPTimeZone and the host's local time rules.
As we have a tool-free bridges between many classes and JavaScript types by setting the isa property on the type, for example CPArray and Array. Using the for...in enumeration the isa property will be included in the loop if the property is enumerable (this is the default behavior). This commit set the property as not enumerable.
Also added test case for check that the isa property on classes are not enumerable using a for...in loop.
Previously, when making a CPDate with some constructors, we could pass a string or nil to create a date. For example it was allowed to do var date = [CPDate dateWithTimeIntervalSince1970:"10"];
Now this is not possible anymore and it works like in Cocoa, only number are authorized.
Apparently this will return false for equal dates, reverted the actual equality check to what was already in Cappuccino before my fix !(date < otherDate || date > otherDate)