Re: [boost] [locale] Formal review of Boost.Locale library starts tomorrow

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.