Markus, Fabian, and all:
Lots of code in this patch. Now that the Gregorian and Julian
conversions and back-conversions have been proved, this patch will
create a version that computes and outputs both. Specifically, it:
1. Adds another set of day, month, and year parts.
2. Creates separate caches for a Gregorian and a Julian printout value.
3. Loads each set of year-month-day properties according to a calendar
model that is either specified or worked out from the input. By default,
the model to be used to create the Julian Day is the Gregorian, if the
date is October 15, 1582 or later, and otherwise the Julian. But the
user may override this rule by specifying "Gr" or "Jl" in his input. (If
he uses "OS" in English, that means "increment the year if the date
falls between 1 January and 24 March inclusive, and treat the resulting
date as Julian."
4. Performs /both/ back-conversions and stores each result separately.
5. Preserves the imprecision of the input, i.e. a month and a year as
input produces only a month and a year as output in each model.
6. Selects the printout value for the browser as follows: any date
having a JD less than the date of the Gregorian calendar proclamation
will be Julian; otherwise it will be Gregorian.
7. Creates "tooltip captions" that show the Gregorian value, then the
At this point I'm open to suggestions as to which outputs would be
preferable. I can now produce whatever output is desired.
Now that I have shown this, I will proceed to implement the two other
calendar models that I mentioned.
The next step after that will probably be the transfer of these
improvements to the current version. Only then will I be in a position
to add the calendar model as another DBkeys element, probably $args.
(How many elements is $args permitted to have in the functions
getDBKeys() and parseDBkeys($args)? I had the distinct impression that
in SMW 1.4.2, the answer was two, corresponding to the old arguments
$value and $unit.)
Get latest updates about Open Source Projects, Conferences and News.