VASmalltalk – ICU, UCalendar 0.2.0

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.

External Resources
Like all instances handled by ICU, instances of UCalendar are external resources and you should free it by sending #close to the instance.

ANSI API
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.

Unicode API
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
Conversions have been added between Date and UCalendar, Time and UCalendar and of course DateAndTime an UCalendar.

Printing
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.

Speed
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 DateAndTime now.

Tests
Many more tests have been written for UCalendar

This entry was posted in Smalltalk and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s