Only one worry presented itself to me as I read the docs. Consider the
following example:
date_time some_point = period::year * 1995 + period::january + period::day*1;
It looks like a period can be implicitly cast to a date_time. This seems dangerous. I feel the start of 1995 should be obtained more explicitly through the calendar.
Actually date_time by default initialized to current time. So if you set a year 1995 it would be today's date and time back into 1995.
I prefer not to use explicit cast as it makes life much easier for users and also
period::year * 1995 + period::january + period::day*1
Is a periods set has its own type that are set later together.
An explicit cast is not the alternative I was considering. I feel something like
date_time some_point = gregorian_calendar.year(period::ad, 1995) + period::january + period::day*1;
would make more sense.
The point is you generally want to use global locale by default that defines the calendar. So basically you can do: date_time gregorian_time(some_locale); gregorian_time = period::year * 1999 + ...
I think I was confused about what a date_time actually is. I was thinking about it like a POSIX time, which needs an associated calendar to give it a human-readable description, but on closer inspection I see that this is not the case. I think you should clarify the description under "Handling Dates and Time"; the current "represents a time point. It is constructed from a calendar and allows manipulation of various time periods." doesn't really give enough clue as to how the programmer should be thinking of its semantics.
I'll probably try to clarify. date_time object is the object that has following properties: - Time - independent representation of time point (posix time) - Calendar - how to operate on the dates and times in currect calendar rules. Meaning what should I do when I want to change a date 5 days later (what changes months etc) and what happens to local time (Summer time period) and so on. So given time point it defines an operations on it - how to handle time in human periods (days weeks years months, hours etc) The textual representation (output) is different story and it is done on other level.
- Just how general is the calendar format here?
What do you mean?
ICU supports several calendars (Hebrew, Islamic, Japanese, Chinese and some
more) and their support vary by ICU version.
Sorry, I never finished writing that paragraph. I meant to say:
Will it support for example the French Revolutionary Calendar, or the Mayan Calender?
http://en.wikipedia.org/wiki/French_Republican_Calendar http://en.wikipedia.org/wiki/Mayan_calendar
I'm guessing the former would work in theory if ICU supported it, but the latter is too different to be meaningful.
I'm not so sure about the two above. Currently icu 4.6 supports following calendars: "gregorian", "japanese", "buddhist", "roc", // republic of China "persian", "islamic-civil", "islamic", "hebrew", "chinese", "indian", "coptic", "ethiopic", "ethiopic-amete-alem", As far as I know all have months, years and weeks, however even supported calendars have their weakness. For example, Hebrew calendar (lunar based one) that is active in Israel (my country) is not entirely correct in ICU. Why? Because dates are changed at sunset and not in 12AM. However in order to handle this information correctly you need to know exact geographical location of the user (latitude and longitude) so this isn't something known to the computer (unless it has GPS) So some assumptions are already made and has effect on its correctness. I can say safely: there are no safe assumptions... As you can see in the example I had shown. But some has to be made because otherwise programming wouldn't be possible, so you can assume that there are years, months, days and weeks and so on...
My point is: it would be helpful to give an impression of what properties a calendar must have for this abstraction to be meaningful. For example, must it have years, months, weeks, and days? Perhaps the ICU docs would explain it in more detail, in which case a reference to that would suffice. At present you simply have a warning "Be very careful with assumptions about calendars.", but no indication as to what assumptions *are* safe to make.
Almost nothing, number of months can vary, first day of months may be not 1 and so on. Best is to use minimal and maximal ranges for current time in calendar. The problem is that there are no easy way to define because there almost certainly would be something that you forget. The question is whether it is important or not. For example almost all software I had seen does not handle the change of date on sunset correctly for Hebrew calendar - and it is fine for most purposes. But software that was especially written for Religious purposes has additional input of geographical location and does handle Hebrew date change correctly (and it does not use ICU). Artyom P.S.: Basic thing to understand is when you deal with localization is that it is limitless and with very high confidence you can say that even most generic software misses something for some culture and it can be discovered only by real users.