User:Temlakos/practice/devlog

Archive of Developmental Logs:

The Standard Date Datatype

Today I tested the standard Date datatype for the first time since Markus Kroetsch introduced his modification.

I already knew that his datatype was full of errors. I did not know that I would find one so soon, or that I would miss it in examination. He adds the time offset to the Julian Day, when in fact he ought to subtract it. Result: a time annotated in Romeo Time is misinterpreted as midnight UTC when in fact it should be midnight HAST and 1000 UTC.--Temlakos^Talk 23:41, 29 July 2009 (UTC)

Test: Subtract rather than add the time offset, and use internationalization methods for 12-hour clock annotation. Result: Failed; not understood.--Temlakos^Talk 23:59, 29 July 2009 (UTC)

Test: Roll back internationalization of am/pm. Result: Success, so long as the offset directly follows the time with no intervening whitespace. Time is correctly given as 10:00:00 UTC.

Test: Replace Markus' regex with my case-sensitive regex for am/pm ([ap]m). Result: Success.

Test: Add a line just to call the language-specific get function for the regex. Result: Success.

Test: Predicate the browsing on the returned regex not being false. Result: Success.

Test: Actually use the regex to browse the input value. Result: Failed.

Test: In the file SMW_LanguageEn.php, drop the "/" and "/u" substrings from the string $m_rgxampm. Result: Failed.

Test: Roll back language-file change, and restore the insertion of a directly written regex string. Result: Success.

Test: Browse with a regex that is "good" for all variations on the am/pm theme, in all alphabets—Roman, Cyrillic, Korean, Chinese. Result: Success.

Test: After browsing, "find" the am/pm designator and store the key. Result: Success.

Test: Annotate a date in the pm rather than the am. Result: Success.

Test: Annotate with Chinese pm characters. Expected result: "NoDateTime" error. Result: Processed as a morning time.

Test: Annotate with pm, as a prefix rather than as a suffix. Result: Proper processing.

Test: Annotate with capitalized PM as a suffix. Result: Fails to process.

Conclusion: A comprehensive regex will substitute well for 12-hour annotation detection and processing. Individualized regex "getting" appears to fail. Suspected problem: Return values of strings are unpredictable and not as documented, or else regexes cannot be stored in that manner.

TODO: Develop comprehensive calendar-browsing regex for all calendar symbols in all languages. (This regex is limited to 255 characters!)--Temlakos^Talk 01:29, 30 July 2009 (UTC)

Test: Scrub the am/pm array and regexp stored values, and store a regexp for finding calendar models. Result: Success.--Temlakos^Talk 15:14, 30 July 2009 (UTC)

Test: Use the regexp to look for calendar models. Result: Page continues to load.

Test: Annotate the Ides of March in 44 BC. Result: Success.--Temlakos^Talk 17:14, 30 July 2009 (UTC)

Test: Call on the language-specific array for the calendar model. Result: Success

Test: Annotate the Ides of March with BCE symbol. Result: Success

Test: Establish a default calendar model. Result: Success

Test: Load the m_tz array. Result: Page refuses to load

Test: Load part of the array: one line, having negatives and floats. Result: Success.

Test: Load the second line in that array. Result: Success.

Test: Load the third line. Result: Success.

Test: Load the fourth line. Result: Success.

Test: Load the fifth line. Result: Success.

Test: Load the sixth line. Result: Success.

Test: Load the seventh line. Result: Success.

Test: Load the eighth line. Result: Success.

Test: Load the ninth line. Result: Success.

Test: Load the tenth line. Result: Success.

Test: Load the eleventh line. Result: Failed.

Test: Split the array at the seventh line and load the first line of a second array. Result: Success.

Test: Load the second and third lines. Result: Success.

Test: Load the fourth line. Result: Success.

Test: Load the fifth line. Result: Failed.

Upon close inspection, discovered that one of the key-to-value operators was mis-keyed.

Test: Load the entire array after changing a -> to a =>. Result: Success.

Test: Load in the function that finds a time-zone moniker. Result: Failed; annotated dates no longer understood.

Conclusion: The regex, which contains single letters, is picking off those letters.--Temlakos^Talk 19:13, 30 July 2009 (UTC)

Test: Use a regex that does not search for single letters. Result: Success.

Test: Re-annotate the November date with the EST moniker instead of an offset. Result: Failed; not understood.

Test: Reconfigure $regexpcal to insist on He and Cyrillic "Iv" instead of one-letter symbols. Result: Failed; offset not used.

Test: Remove "offset falsity test." Result: Failed. Re-examination: offset was measured in days, not hours.

Test: Divide the retrieved offset by twenty-four, and then add it in. Result: Success. Annotation understood, and EST correctly translates as "add five hours to get the UTC time."--Temlakos^Talk 21:05, 30 July 2009 (UTC)

Test: Add code for recognizing military time, and annotate a date in military time (time zone Romeo). Result: Failed; neither military nor civilian times understood. (The date without a time was unaffected.)

Test: Move military-browsing code to appear after the civilian time code. Result: Failed. Regex Tester reveals the problem: the military regex strips out a four-digit year.--Temlakos^Talk 21:59, 30 July 2009 (UTC)

Test: Make the one-letter military time-zone suffix mandatory. Result: Success.--Temlakos^Talk 23:34, 30 July 2009 (UTC)

Test: Add member variables for preference and AM and He calendars. Result: Success.

Test: Change various common array declarations from "protected" to "private static" and use self:: referencing. Result: Success.

Test: Add several more private static arrays necessary for the next code. Result: Success.

Test: Add several more members, and change the checkDigit method to support three sets of years, months, and days. Result: Success.

Test: Refine the checkDigit method to be more exacting with its format assignments for digits. Result: Success.--Temlakos^Talk 01:57, 31 July 2009 (UTC)

Test: Expand the three-digit parser to use the "am" or "h" variables when the calendar model so demands. Result: Failed; annotated dates not understood. Close inspection reveals a missing variable marker.

Test: Replace the variable marker. Result: Failed; annotated dates still not understood.

Test: Refine the test for a missing preference. (Preferences are set well enough when specified.) Result: Failed; annotated dates not understood.

Test: Roll back all changes to the three-digit parser. Result: status quo ante.

Test: Add back the five enhancement lines. Result: Success.

Test: Add back the missing variable marker. Result: Output unaffected, as expected.

Test: Add in error checks appropriate to the AM and He models. Result: Output unaffected, as expected.

The next code to test for suitability will be the actual calendar-model code. However, reconsideration of the ISO8601 standard necessitates a revision of the object model.

At issue: ISO8601 dates of the format YYYY-MM-DDTHH:MM:SS are proleptic Gregorian dates. This absolutely requires storing both the Gregorian and the Julian dates in all eras.

The following new code will now be required:

Member properties:

• protected $m_dayj
• protected $m_monthj
• protected $m_yearj

These variables, and not the base variables, are to be loaded if the property $this->m_pref is either BC(E) or OS.

The base variables will remain the basis of $m_xsdvalue. The printout value will depend on the calendar model.

The calendar model will be returned as the second member of the DBKeys output array, and will be parsed as argument 1 (the XSD value is argument 0).

---

DISASTER. Unable to track an errant character; forced to roll-back every change to the original file. Result: Status quo ante all revisions.

Test: Add several new member properties. Result: No hangs.

Test: Add all remaining private static arrays and constants. Result: No hangs, but first date is not understood.

Test: Add code for parseUserValue up to the am/pm annotation code. Result: No hangs, but three out of four dates are misunderstood.

Test: Add in replacement code up to (but not including) military time browser. Result: Same as above.

Test: Replace military-time code and first part of parser for dates proper. Result: Same as above.

Test: Replace checkDigit code. Result: Same as above.

Test: Replace all remaining code for date parsing, including error checks. Result: No hangs, and all dates are properly parsed. However, the time offsets are misinterpreted.

Test: Change a + sign on the time-offset handler to a - sign. Result: Time offsets calculated as desired.

Test: Add code to direct loading of "am" and "h" properties. Result: Output unaffected.

Test: Add error-checking code for the "am" and "h" variables. Result: Output unaffected; system appears stable.

File copied out of the site for archiving.--Temlakos^Talk 22:23, 31 July 2009 (UTC)

Test: Change another sign: one must subtract, not add, half a day for a pm notification to the time offset. Result: Success; pm annotations now translate properly.

Test: Add the code for the protected static function "createTime." Result: Success; no hanging, and output not affected. (The function is not called yet.)

Parsing of times, time zones, direct offsets, twelve-hour annotations, and year-model symbols is now fully proved.--Temlakos^Talk 23:36, 30 July 2009 (UTC)

File copied out of the site for archiving.--Temlakos^Talk 23:56, 31 July 2009 (UTC)

Test: Expand the getYear function to accept an optional parameter for any calendar model. Default is "GR" for "Gregorian." Result: No hangs, no misinterpretations.

Test: Expand the getMonth function in the same manner, with two optional parameters. Result: No hangs, no misinterpretations.

Test: Expand the getDay function in the same manner. Result: No hangs, no misinterpretations.

Test: Add year-model parameters to the function getXMLSchemaDate to conform to the new getMonth and getDay functions. Result: No hangs, no misinterpretations.

Test: Overwrite the function getUnit() (from the parent class) to return the calendar model listed in m_pref. Result: No change in output.

Test: Add a call to unstub() to getUnit(). Result: No change in output.

Test: Revise parseXSDValue($value, $unit) to store $unit as $m_pref. Result: No change in output.

Test: Strike the unstub() call (not necessary in this version), and add three protected static functions for creating a Julian day from Gregorian values. Result: No change in output.

Test: Added functions to convert to and from Gregorian dates, and to "preserve imprecision." Result: No change in output.

Test: Added functions to convert to and from Julian dates. Result: No change in output. Note: Conversion back from negative Julian days will not be supported. Instead, the printout value will have its basis on Julian numbers only. (Proleptic Gregorian numbers are not valid for negative Julian days.)

Test: Revise checkDigit to use the "j" variables for all BC, BCE, and OS dates. Result: No hangs, but the BC date is now "misunderstood." (Expected; the regular date variables are now empty.)

Test: Revise the three-way parser to use the "j" variables for BC(E) and OS dates. Result: Same as above.

Test: Correct one error check and the function of the isyearbc variable. Result: Same as above.

Test: Added code for a signal variable $model to direct the conversion, and for moving values to Julian variables if an AD date is earlier than 15 October 1582. Result: Same as above.

Test: Copy the model-finding code to a separate protected function, so that parseUserValue and parseDBKeys can both call it. Result: Same as above.

Test: Replace existing model-finding code with a simple function call. Result: Same as above.

Test: Add a new makeJD($mod2) function to direct the calling of various other functions. Result: Same as above.

Test: Add the timeStrFromJD() function to convert JD mantissae to time strings. Result: Same as above.

Test: Expand the makePrintoutValue() function to support all models. Result: No hangs, same captions are good, but the printout values are all "0" plus a time string. Probable cause: the new function assumes that a Julian day was created, and that's not yet the case.

Test: Roll back the makePrintoutValue() function. Result: Status quo ante.

Test: Add a missing suffix to the error-check routines. Result: The BC date is now properly "understood," but the printout value is now "1 BC." Possible explanation: no JD is created (no time offset given), and nothing appears in the variables searched by the makePrintoutValue function.

Test: Add a function called makeJD($mod2) that calls an appropriate function for making a Julian Day with a specified calendar model. Result: Page hangs; rollback required.

Test: Correct one line in gregorian_to_jd to call getMonth rather than querying the member property. Result: Status quo.

Test: Add another version of makeJD based on "if" instead of "switch." Result: Page hangs. Rolled back.

Test: Try again with the function, now titled convertJD($model2). Result: No hangs. Conclusion: either "make" is a not-allowed part of a function name (not likely), or a mysterious invisible character had become part of the code and was eliminated when I retyped it.--Temlakos^Talk 00:49, 3 August 2009 (UTC)

Test: Add a function to call all back-conversion functions at once. Currently uses the Julian and Gregorian only (the others do not yet exist). Result: Status quo.

Test: Use my functions instead of the originals, and remove another version of makeJD($). Result: Page does not hang, but the printout values are wrong: the "pm" symbol goes unrecognized, and a BC date prints out as 506 BC.

Test: Rollback. Result: Status quo ante.

Test: Second attempt to use my functions. Result: Same result; time offset is totally ignored. Rolled back.

Test: Third attempt, this time after correcting an error in timeStrFromJD() that was ignoring the actual time string. Result: the Gregorian dates translate and print out properly with their times, so the time offset is not ignored. But the Julian date is showing up as "506 BC."

Test: Add a line to JD2Dates() to test for a "false" value of m_time, to control the generation of a time string at printout. Result: Success. Time string is suppressed if it was never specified at annotation.

Test: Add a line to recognize is_yearbc ahead of the parsing. Result: No change; all BC dates are interpreted as "506 BC."

Test: Add several lines to abort back-conversion if the Julian day is negative. Results: No change.

Test: Call the original back-conversion function. Results: Gregorian dates interpreted half a day behind, as expected. Julian dates all resolve as 31 December 2 BC at noon.

Test: Invent and utilize special getYearJ, getMonthJ, and getDayJ functions. Result: No change; same erroneous output for all Julian dates.

Test: Rollback special functions, and add more parens to a trinary conditional expression for variable $year. Result: No change.

Test: Modify makePrintoutValue to pick the Julian year/month/day set if the Julian day is less than the switchover day. Result: All dates print out as "year one." Rolled back.

Test: Modify julian_to_jd to avoid saving any results from the "get" functions. Result: No difference.

Test: Modify the declaration of m_jd so that its default is zero, not "false" or empty string. Result: No change.

Test: Suppress the erasure of Gregorian variables during transfers from Gregorian to Julian (say, for AD dates before October 15, 1582). Result: Columbus Day now prints out exactly as annotated; all other Julian dates print out as 506 BC.

Test: Roll back above changes, remove calls to createJD() from getNumericValue and getHash, and add a call to gregorian_to_jd() to parseXSDValue. Result: Gregorian dates parse as usual, but Julian dates now parse as 1011 BC (another 506 years subtracted!).

Test: Remove the calls to the conversion functions from makePrintoutValue(). Result: Status quo ante.

Letter sent to Markus Krötzsch and Fabian Howahl on this date.--Temlakos^Talk 02:07, 6 August 2009 (UTC)

Markus' answer: hasn't time to deal with matter immediately.--Temlakos^Talk 15:05, 8 August 2009 (UTC)

Test: Scrub all references to separate Gregorian and Julian models; same variable set used for both. Result: the 506 BC phenomenon is no longer a problem, but the printouts of Julian dates are not accurate; many of them appear to fall three weeks or two years or even eighteen years off-target.--Temlakos^Talk 15:08, 8 August 2009 (UTC)

Test: Suppress the JD conversion in parseXSDValue unless the "preference" is AM or He. Result: Julian dates are still "off," but by not as many days. 1000000 BC resolves to 100001 BC.

Test: Replace control structure in convertJD($model) with a switch(){} statement. Results:

• All Gregorian dates accurate.
• Columbus Day now completely accurate.
• Old Style date resolves to the old style value, and not the new style value.
• Ides of March resolves to exactly one year earlier than actual.
• 100000 BC resolves to 1000001 BC.

Test: Remove the suppression on the conversion functions in parseXSDValue. Result: Exactly the same!

Test: Remove the year adjustment from the makePrintoutValue() function. Result: BC dates now resolve accurately. Old Style date still resolving as Old Style, not New.

Notice: Time offsets not processing properly.

Test: Change switch statement to end in a default in convertJD($model). Result: No change; time offsets still not properly processing.

Decision: Revert to original version and start rebuilding, step by step.--Temlakos^Talk 14:41, 10 August 2009 (UTC)

Test: Restore original version of SMW_DV_Time.php. Result: Printout values are proper, except that time-zone monikers and military time strings produce errors, as does the "OS" moniker.

Test: Add back the time-zone moniker code. Result: Page hangs. Rollback required.

Test: Add the m_tz array. Result: Status quo.

Test: Add the code for browsing for time zone monikers (civilian context). Result: Time-zone monikers are recognized (after an improper character is removed from the code), but the offsets are miscalculated.

Test: Restore all added time-string handling after removing spurious variable markers. Result: All dates except the OS date parse recognizably, and all printouts indicate correct calculation of time offsets.

Patch generated and sent to the chief developers of this script, for purpose of adding comprehensive time-zone support by moniker as well as by explicitly specified offset (and correcting the current inconsistent handling of time-zone and twelve-hour offsets).--Temlakos^Talk 20:36, 10 August 2009 (UTC)

Test: Add support for Julian calendar. Result: Page loads, and all dates annotate and calculate correctly.

Test: Annotate the date "October 13, 1582" (which, strictly speaking, never existed). Result: It calculates as October 3, 1582, as it should for the Julian calendar.

Test: Reload the file after editing some of the comments to make them reflect current alterations. Result: Same as above.

Second patch made and sent.--Temlakos^Talk 03:13, 11 August 2009 (UTC)

Test: Add Old Style support and also have the XSD Value parsed. Result: Old Style support works properly, but some of the incomplete dates are not parsed properly, and 1000000 BC resolves to a year considerably later.

Test: Remove the conversion routines from parseXSDValue(). Result: The 1000000 BC date processes correctly, but all the Julian AD dates parse incorrectly. (The BC and OS dates parse correctly.)

Test: Roll back all changes. Result: Status quo ante.

Conclusion: Old-Style support works, but it interferes with Julian date processing.

Re-examination: The regex is [ABOabo][DCSdcs]. That would match the "Oc" in "October." There is where the fault lies.

Test: Rewrite with a strict case-sensitive regex for calendar models. Result: All dates parse properly, and OS support works as intended.

Third patch created and sent.--Temlakos^Talk 15:09, 11 August 2009 (UTC)

Test: Add "Gr" and "Jl" symbols to be used to specify, i.e. force, an AD/CE date to be either Julian or Gregorian, regardless of epoch. Result: Gregorian symbol appears to work, but Julian symbol does not; the annotated date and the browsed date are the same, though they shouldn't be.

Test: Change "This->" to "this->" in the line calling for recognition of the "Jl" symbol. Result: "Jl" symbol now recognized, in that 30 October 1917 Julian now browses as 12 November 1917 Gregorian.

Fourth patch created and sent.

Test: Repackage code for finding a month from a label to place that in its own function. (This code will soon be called twice.) Result: Same as current; no adverse effects.

Test: Set up separate Gregorian and Julian date-part sets and do conversions for both at once. Result: Page hang. Reverted to last known good.

Test: Try again, after adding a missing closing curly brace in getYear($model,$default). Result: Dates with times won't parse. All other dates have proleptic Gregorian printouts.

Test: Add a condition to the 4713 BC error check (that m_year be false). Result: All dates and times parse as expected; proleptic Gregorian dates appear in the browser.

Test: Add code to prepare two different printout values, and to choose between them according to epoch. Result: Article captions unchanged; browser captions are Gregorian or Julian according to epoch, and are accurate.

Test: Add tooltip code to show a Gregorian and a Julian value, one below the other, in a balloon. Result: Tooltip balloons appear on all annotated dates, showing Gregorian, then Julian, values, as planned.

Fifth patch created and sent.--Temlakos^Talk 01:13, 12 August 2009 (UTC)

Test: Change maximum allowable days in February from 28 to 29 to allow for leap-year annotations, and annotate two dates with "February 29" in them, one in a leap year, and one not in a leap year. Results: Both dates parse; the leap year is recognized as such, and the other date resolves as "March 1" in the Gregorian calendar (and February 16 in the Julian).

Quick patch created and sent to correct this oversight.--Temlakos^Talk 12:17, 12 August 2009 (UTC)

Test: Change certain never-altered arrays from protected arrays to private static arrays, and change certain functions that never access member properties to static functions, and change identifiers from $this-> to self::$ or SMWTimeValue:: as appropriate. Result: Page hangs. Reverted to LNG.

Test: Change five protected arrays that are never modified, to private static arrays, and change their identifiers from $this->m_x to self::$m_x. Result: Success.

Sixth patch created and sent.

Test: Change the function findMonth to a static function, and apply a proper scope-res ID. Result: No hangs.

Test: Change both normalization functions to static functions, and apply scope-res IDs. Result: Success; no hangs.

Seventh patch created and sent.--Temlakos^Talk 14:49, 12 August 2009 (UTC)

Test: Load the Hillel II model. Result: No page hanging, but the Hillel values are not appearing in the Tooltips.

Test: Add a line to getShortWikiText($linked) to call makeHillelValue(). Result: Hillel dates appear in Tooltips, but with negative years.

Test: Change the sign of the years in makeHillelValue(). Result: Positive years.

Test: Examine Tooltip Hillel years for accuracy. Result: No errors.

Test: Annotate a Hillel date. Result: No errors.

Eighth patch created and sent.--Temlakos^Talk 22:46, 12 August 2009 (UTC)

Test: Add AM model and direct processing of hashtag #CREATION and Julian Days. Result: No page hanging, but 1963 processes as 4708 BC, and some AM dates do not print with day 1.

Test: Reconfigure direct Julian Day processing to require that all such inputs be floats, not integers. Result: Page hangs.

Test: Remove direct JD processing code altogether. Result: Page is safe; 1963 processes properly. However, #CREATION parses with a very low-precision format.

Test: Add code to call fracToTime() and set the format to 3 (all three parts). Result: #CREATION gains a precision tooltip and caption.

Test: Add code to "roll back" the month any time a day computes as zero. Result: Rollback code checks out; "zero" days resolve properly.

Problem: "Tammuz" will not parse. Probable cause: "am" gets stripped out by the am/pm regex.

Test: Add \040 to that regex to require a space before the "am". Result: Problem solved.

Problem: All dates annotated as AM end up processing at 3762 BC. Probable explanation: Problem with the am_jd function, which never gets called by the back-conversion routine.

Test: Change "floor" function calls to "intval" function calls within that function. Result: No change.

Test: Remove the am_month_days function that calls am_jd, and remove all calls of that function. Result: No change, but page does not hang, so the removal appears safe.

Test: Revise am_jd code to be a protected non-static function and pass the JD directly to the proper register. Result: Same error, but code appears safe.

Test: Annotate "1 Tishrei 1 He." Result: That resolves to 7 October 3761 BC (Jl).

Test: Comment out most code in am2JD() and replace it with a simple instruction to save constant "VE2000" to m_jd. Result: No change! Conclusion: The am2JD() function is not even getting called! The hebrew2JD() function is getting called instead—and because all the Hebrew values are false, HEBREW_EPOCH is getting stored, and that resolves to 3762 BC.

Re-examination: The output values were switched in the Tooltip dialog.

Test: Switch those member calls to where they were intended. Result: Julio-Gregorian, AM, and HE printouts appear in their proper order, and now appear in the very earliest dates (except 1000000 BC). AM-annotated dates are printing out as 3762 BC and 242 AM, consistent with HEBREW_EPOCH.

Re-examination: "break" statement missing from a "switch" structure. This was causing createJD() to call hebrew2JD() after am2JD() and suppress its actions.

Test: Insert the break statement, and restore am2JD() to its original form. Result: Success! All AM dates process properly and accurately.

Ninth patch created and sent.--Temlakos^Talk 21:53, 13 August 2009 (UTC)

Test: Added code for processing Julian Days (JD) and Modified Julian Days (MJD). Result: Code is safe, but the JD does not parse at all, and the MJD parses with a strongly negative value.

Test: Change the regex and the sign on the MJD correction. Result: Success.

Alternate version of Patch.9 created and sent.--Temlakos^Talk 00:13, 14 August 2009 (UTC)

Test: Add code to recognize BCE and CE and use it in Gregorian or Julian outputs, if specified. Result: Code is safe, but the Gregorian printouts suppress the year and add all manner of symbols.

Test: Roll back. Result: Status quo ante.

Test: Reimplement (B)CE support and also implement passage and processing of the calendar model as a "unit." Result: Code is safe, and tooltips are changed as expected, but browse printouts are unchanged.

Test: Change getLongWikiText($linked) to offer the enhanced, unit-controlled printouts. Result: As desired.

Test: Test-annotate a CE date and a BCE date. Result: CE and BCE labels propagate as intended. Test of XSD parsing will have to await a definitive test of querying, but for now, browsing appears to be fully supported.

Tenth patch created and sent.--Temlakos^Talk 19:03, 14 August 2009 (UTC)

Next step: Full internationalization.--Temlakos^Talk 20:38, 14 August 2009 (UTC)

Test: Install internationalization function calls in the Time script, and internationalization codes and symbol arrays in the Language and LanguageEn scripts. Result: Code is safe, but the "Gr" and "Jl" symbols do not override the epochal selection, the am/pm will not annotate, and neither will the JD and MJD.

Test: Add two parens to smwgContLang->getRgxAmPm call. Result: am/pm now annotates, and processes, correctly.

Test: Complete an incomplete calendar-symbol array in the LanguageEn file. Result: All correct!

Final patches (Patch 11 of the script itself, and a patch for all the language files) created and sent to SMW developers. SMW tar.gz file prepared to install new version of SMW_DV_Time.php and language files in all directories. Patch file created showing updates necessary to make SMW_DV_Time.php work with SMW-1.4.2.

Plan:

1. Install new modification of SMW-1.5bSVN everywhere.
2. Rewrite the legend for Type Date to reflect its developmental history.
3. Change all properties of type Historical Date to type Date instead.
4. Reannotate all dates having years of the form [0-9]{4}[a-d]. This format is not supported; imprecise dates may have a year only, or a year and a month.
5. Reannotate the launch date of Voyager 2, if possible, to give an exact date and time.
6. Migrate SMW_DV_Time.php to SMW-1.4.2, using the above-mentioned patch as a guide.
7. Prepare and install SMW-1.4.2.
8. Delete the reference to "Historical Date."

--Temlakos^Talk 03:01, 15 August 2009 (UTC)

Test: Install new SMW_DV_Time.php and all language files in all directories and subdirectories. Result: New code is safe.

Test: Change the datatype of Property:Date from Type:Historical date to simply Type:Date. Result: After multiple saves and re-saves, all dates annotated with that property now behave as desired with the improved standard datatype.

Test: Repeat this change on the French side. Result: Same, i.e. success.

Test: Reannotate many instances of a date annotated with months and years only. Result: Date annotates properly when the property type is changed. But the browse and query listings fall one month back.

Test: Change the XSD get and parse functions to pass and accept various date models, to preserve position. Load new version into the English side. Result: Code is not safe.

Test: Add a missing symbol to a function declaration. Result: Code still not safe.

Test: Replace a stray semicolon with a comma. Result: Code is now safe, but it fails. Printouts are not given at all.

Test: Roll back and refresh as necessary. Result: Status quo ante.

Final decisions:

XSD format not changed. It will remain as is: a proleptic Gregorian date with empty values if parts of the date are false.

To solve the problem of month fallback, advance the month by one if the day would have been the second day or later. (That might change later on.)

Code successfully ported to SMW 1.4.3 and installed. It is successful. Another version was sent privately to another wiki admin who requested it.--Temlakos^Talk 22:11, 22 August 2009 (UTC)