And just for kicks, the JavaScript date class returns different values for older dates than the Java class, and neither of them deal well with older dates, time zones, and date manipulation anyway. But, for normal applications using modern dates in a standard, simple way it is adequate, and importantly lightweight. A true Calendar-type class set requires a substantial amount of code that would have to be sent to the client, bloating your app download size - just so you can get what year it is.
In reality, the "deprecated" Date object is simply used as an interface, as GWT just uses it to wrap the JS date class calls anyway. So, besides the annoying warnings which can easily be turned off, why write a new GWT specific API to do the same wrapping? Seems it would be better to write a real correctly working Calendar class for those few apps that actually need the advanced functionality. For my app I've actually had to write very correct calendars that span all of time (15BY, not 6000YA...), including functions like the roll and getting the number of days in a given month/year like Java's class. With Gregorian/Julian/Proleptic/Astronomic versions it turns into about 10k of compiled js. Unfortunately it's probably too detailed to push out as the open source general calendar solution for GWT.. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
