Markus and Fabian:
Attached is a quick patch to the JD2Gregorian() function of
SMW_DV_Time.php. The effect of this code is: "If the format is an
imprecise format calling for a month and a year only, and if the day of
the month is greater than the second day, kick it up to the next month."
The effect of this is apparent mainly in the XSD Value (soon to be the
first element of the DBKeys arguments). With this refinement, when you
browse the properties of an article, or query an annotated date in
another article, if you have annotated it in a different model
(especially the Anno Mundi model, but also in the Hebrew model), the
DBKey parser will still deliver the same month and year that appears in
the original article, and not fall one month back as it has been doing.
It also changes the tooltip dialog message. Recall that when you use
months that follow the moon very closely (or, in the Biblical calendar
case, almost exactly), and then convert to a model that does /not/
follow the moon, a month in one model will "straddle" two months in
another. All I did was to make sure that the proleptic Gregorian month
would be the /later/ of the two months that fall partially within the
span of a lunar or lunisolar month. As to restricting this change to
dates greater than the second day, that is a crude adjustment meant to
strike a compromise and keep to a minimum any problems resulting from
annotating in Julian and then parsing a database key in proleptic
Gregorian. In the latter case, insisting on advancing the month after
the first day might produce the opposite problem: an unwanted
advancement of the month when I sought originally to maintain the status
quo.
Annotations of regular Gregorian dates will not, of course, be affected
by this change. Nor will any dates annotated with a year, a month, and a
day, or anything more precise than that.
This does not require any changes to the existing args[0] value, nor the
addition of any further elements to the return value of getDBkeys(). It
does require a data refresh to make the effects felt in all articles. In
particular, this totally obviates the passing of the Julian Day value in
queries.
I examined closely the code for the SMW store. I found that the store
will not yet "store" anything but the original XSD value and unit, now
known as args[0] and args[1]. Thus adding a value would have slowed down
the execution of a query or a browse. Now that will not be necessary.
Soon I will attempt to upgrade to SMW 1.4.2 and then to 1.4.3, now that
I have been able to declare my old custom data type obsolete.
Temlakos
--- /home/temlakos/tools/CreationWiki/SemanticMediaWiki-lng/SMW_DV_Time.php
2009-08-16 17:55:41.000000000 -0400
+++ ./SMW_DV_Time.php 2009-08-19 08:28:55.000000000 -0400
@@ -976,6 +976,13 @@
$this->m_year = $y - 4800 + intval(($m + 2) / 12);
$this->m_month = ($this->m_format >= 2) ? (($m + 2) % 12 + 1) :
false;
$this->m_day = ($this->m_format == 3) ? ($d + 1) : false;
+ if(($this->m_format == 2) && ($d > 1)) {
+ $this->m_month++;
+ if($this->m_month > 12) {
+ $this->m_month = 1;
+ $this->m_year++;
+ }
+ }
}
// Function to produce a (proleptic) Gregorian year only--used by the AM model
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Semediawiki-devel mailing list
Semediawiki-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
