Boost logo

Boost :

Subject: Re: [boost] [locale] Formal review of Boost.Locale library starts tomorrow
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-04-08 14:06:07

On 08/04/11 11:57, Artyom wrote:
>> 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.

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.

>> - 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?

I'm guessing the former would work in theory if ICU supported it, but
the latter is too different to be meaningful.

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at