In our current system, each generation starts when the incrementGeneration method is called and ends 14 days later. The call to start the next generation can only be made after the previous generation ends. There is interstitial time between the end of the previous generation and the beginning of the next, and over many generations this time adds up, causing generation start times to drift further and further from where they should be in real time (Ex: if generation 1 runs 12pm January 1st - 12pm January 15th, but incrementGeneration is called at 12:02pm, generation 2 will start at 12:02 pm, two minutes later than it was supposed to).
This proposal remedies generation drift by instead pegging a generation’s end time to the previous generation’s start time, specifying that each generation must end 14 days after the previous generation ended, regardless of when it starts (with an edge case built in for multi-generation gaps between calls to incrementGeneration). The result of this is that the interstitial time (usually a matter of seconds or, at worst, minutes) is deducted from the proposal phase (both community and monetary governance). The difference in time should be barely noticeable from a governance perspective, it will no longer accumulate over time, and generations will now occur on a predictable schedule