Ok, we have reached the version 0.2.0 and for this version most work has been spent in UCalendar class (including locales, timezones, Date, Time, DateTime) and I think, that the interface and layout for UCalendar is now stable and can be used.
Like all instances handled by ICU, instances of UCalendar are external resources and you should free it by sending #close to the instance.
UCalendar has now most (or all ?) of the methods defined by ANSI-API. Therefore I hope, that you may now use instances of UCalendar in lots of situations, where the method expects an instance of DateAndTime.
There are two differences between ANSI-API methods in DateAndTime and UCalendar: #dayOfWeekAbbreviation and #meridianAbbreviation returns different values. #dayOfWeekAbbreviation returns different locale values here in Germany and I would say, that VASmalltalk makes a better job here in DateAndTime>>#dayOfWeekAbbreviation, but I have to check this later.
DateAndTime>>#meridianAbbreviation returns an empty string here in Germany, showing that normally no meridianAbbreviation is used here. In contrast ICU returns just a localized string for AM or PM – if you want to use depends on your wishes.
In addition all ANSI-API calls, which return strings, are also available in Unicode versions – they return instances of Utf16String. These methods have the same name, but a prefix $u (e.g. uMonthName).
DateAndTime also knows these unicode API calls.
Conversions have been added between Date and UCalendar, Time and UCalendar and of course DateAndTime an UCalendar.
In addition to the well known #printOn: method I added several icuPrintOn: methods both in DateAndTime and UCalendar. Therefore you have the same formatting resources available by ICU for DateAndTime and Ucalendar instances. Caution: I think, that these method are not Unicode ready and the implementations might/will change in the future. This will happen, when the unicode stream support is introduced.
Creation of new instances of UCalendar is very time consuming. The creation of an instance of UCalendar is 200 times slower than creating instances of DateAndTime. To get rid of this – some improvements have been done.
If you just want to have an instance with the actual time you may use a statement like
UCalendar now, which returns an (copied) instance of UCalendar (see below: resource in MSKLocale) holding the current time or
UCalendar nowAsDateAndTime, which returns an instance of DateAndTime also holding the current time. This improvement is possible, because the
MSKLocale current helds an instance of UCalendar just for the purpose of getting the current time.
UCalendar now is 20 times faster than
DateAndTime now and
UCalendar nowAsDateAndTime is still a little bit (10%) faster than
Many more tests have been written for UCalendar