[lmi] Inforce dates, durations, and backward compatibility

[Greg Chicares]

I plan to commit the patch below [0] when savannah.gnu.org is
back online. It provides an option to enter inforce dates as
year-month duration pairs, as heretofore, for a while longer.

Without any special argument, the behavior of HEAD won't change.
However, with '--pyx=old_inforce', behavior will be essentially
the same as current production release 'lmi-20090526T1128Z'.
In the long term, we want only dates, not durations: for example,
instead of asking how many months and years ago a contract became
effective, we should just ask for the date as of which inforce
data is supplied. For the nonce, though, we have to support an
obsolete process that gives the duration (month and year).

Requiring a nondefault startup parameter will help us to identify
unauthorized users who shouldn't be running inforce illustrations
anyway. Adding a checkbox might seem to make the system easier to
use, but:
 - It would take extra effort that's better applied elsewhere.
 - It would be throwaway work. Ultimately, we want only dates.
 - At best, it would create yet another field that would need to
     be added manually when pasting to a census.
 - It could cause confusion. When we're given only a number of
     months and years and must make up a date, it could be almost
     one month away from the unknown true date. Checking and then
     unchecking the hypothetical checkbox would change the value.
     It would take time to explain that "fixing" these "problems"
     would be a waste of time.

Dates are more carefully validated than durations ever were. An
upper limit on 'InforceYear' was removed recently, but it's not
worth reinstating conditionally.

'PolicyDate' was removed on 20090526T1212Z, but its value had no
effect, so conditionally reverting that change is pointless. I'm
not sure how it would ever differ from 'EffectiveDate' for a UL
contract. Perhaps someday we should test whether those values are
identical. (Apparently that can't be done in xsd, but could be
accomplished with xslt:
  http://www.xfront.com/ExtendingSchemas.html#Stylesheet
).

There's also no need to revert the 20090526T1331Z changes to
'input_xml_io.cpp', which most significantly fabricate an inforce
date from inforce year and month for xml files previously saved.
Indeed, in the '--pyx=old_inforce' case, the patch [0] duplicates
that logic in order to force the inforce date to an appropriate
value.

Before release, we may rename 'InforceDate' to 'InforceAsOfDate'.
Other names considered:
 - ReproposalDate: if an inforce illustration is run today with
     values as of yesterday, then which would this date be?
 - ReillustrationDate: less common term than "reproposal"
 - ExtractDate: less descriptive than 'InforceAsOfDate' because
     new-business staff may not recognize the term "extract"
 - ValueDate: even more obscure
 - AsOfDate: clearer to say "inforce" specifically
 - InforceDataDate: too easy to parse as a typo

---------

[0] "the patch below":

--- ../../checkouts/current/lmi/input_harmonization.cpp 2009-05-26 
13:31:26.000000000 +0000
+++ ./input_harmonization.cpp   2009-05-28 21:05:28.000000000 +0000
@@ -304,11 +304,21 @@
     InforceContractMonth    .enable(non_mec);
     InforceLeastDeathBenefit.enable(non_mec);

-    // These will soon be removed from the GUI:
-    InforceYear         .enable(false);
-    InforceMonth        .enable(false);
-    InforceContractYear .enable(false);
-    InforceContractMonth.enable(false);
+    if(std::string::npos != 
global_settings::instance().pyx().find("old_inforce"))
+        {
+        // These fields have no effect for now. They're suppressed to
+        // avoid confusion.
+        InforceDate.enable(false);
+        LastMaterialChangeDate.enable(false);
+        }
+    else
+        {
+        // These will soon be removed from the GUI:
+        InforceYear         .enable(false);
+        InforceMonth        .enable(false);
+        InforceContractYear .enable(false);
+        InforceContractMonth.enable(false);
+        }

 // TODO ?? Nomen est omen.
 if(!egregious_kludge)
@@ -950,19 +960,37 @@
         DoHarmonize();
         }

-    std::pair<int,int> ym0 = years_and_months_since
-        (EffectiveDate.value()
-        ,InforceDate  .value()
-        );
-    InforceYear  = ym0.first;
-    InforceMonth = ym0.second;
+    if(std::string::npos != 
global_settings::instance().pyx().find("old_inforce"))
+        {
+        InforceDate = add_years_and_months
+            (EffectiveDate.value()
+            ,InforceYear  .value()
+            ,InforceMonth .value()
+            ,true
+            );
+        LastMaterialChangeDate = add_years_and_months
+            (EffectiveDate.value()
+            ,InforceYear  .value() - InforceContractYear .value()
+            ,InforceMonth .value() - InforceContractMonth.value()
+            ,true
+            );
+        }
+    else
+        {
+        std::pair<int,int> ym0 = years_and_months_since
+            (EffectiveDate.value()
+            ,InforceDate  .value()
+            );
+        InforceYear  = ym0.first;
+        InforceMonth = ym0.second;

-    std::pair<int,int> ym1 = years_and_months_since
-        (LastMaterialChangeDate.value()
-        ,InforceDate           .value()
-        );
-    InforceContractYear  = ym1.first;
-    InforceContractMonth = ym1.second;
+        std::pair<int,int> ym1 = years_and_months_since
+            (LastMaterialChangeDate.value()
+            ,InforceDate           .value()
+            );
+        InforceContractYear  = ym1.first;
+        InforceContractMonth = ym1.second;
+        }

     // USER !! This is the credited rate as of the database date,
     // regardless of the date of illustration, because the database