Subject: Re: [boost] [locale] Formal review of Boost.Locale library starts tomorrow
From: Artyom (artyomtnk_at_[hidden])
Date: 2011-04-08 15:44:42
> >> 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.