我正在维护一个处理某种订阅的Web应用程序。用户可以在到期前2个月（不早于此）续订订阅。有时用户在到期前不会续订并获得3个月的宽限期。现在他可以在这3个月的宽限期内续约。
现在问题部分。在之前的续订请求交易中，我必须显示该特定请求的提供期限（如果授予续订，则为订阅开始和订阅结束期间）。如果用户在到期前更新，事情就非常简单了，但是如果有一个宽限期，特别是当订阅在一年的最后几个月到期时，我就无法直截了当。当订阅以jan或feb结尾时，有时计算也会变得混乱。
所有这一切都在发生，因为提供期不随应用程序一起保存（我不知道为什么）。因此，如果订阅于2008年10月20日结束，并且续订申请于2009年1月16日提交（由于宽限期），则优惠期应为2008年10月21日至2009年10月20日。
如何根据旧续订申请的续订申请提交日期计算正确的要约期？
编辑： - 现在是2010年，假设用户正在查看2009年的过去交易，当时他提交了从2008年10月21日到2009年10月20日期间延长订阅的请求。但他有宽限期并于2010年1月16日要求续约。因为我没有21-10-2008到20-10-2009存储在任何地方我必须计算它是21-10-2008到20-10-2009当请求被记录。这就是我遇到麻烦的地方。
答案 0 :(得分：0)
@TheVillageIdiot，
（A）＆GT;现在是2010年，
到现在为止还挺好 。 。 。
（B）＆GT;假设用户从2009年开始查看过去的交易，
是的，我和你在一起。 。 。
（C）＆GT;当他提交延长订阅的请求时，从2008年10月21日到2009年10月20日 因此，您可以在数据库或日志文件中看到订阅时间为21-10-2008到20-10-2009，对吗？
（D）＆gt;但他有宽限期并于2010年1月16日要求续约 好。但是，此交易日期（16-01-2010）对于订阅的实际开始和结束无关紧要。这是“更新”何时发生的约束的一部分。 （约束的另一部分是你之前提到的2个月之前。）因此，你应该永远不需要考虑一个人何时更新以了解订阅的开始和结束日期。
（E）＆gt;因为我没有21-10-2008到20-10-2009存储在任何地方 等等，然后如何在（C）中知道订阅是从10/08到10/09 ????
（F）＆GT;我必须计算，当请求被记录时，它是21-10-2008到20-10-2009。这就是我遇到麻烦的地方 是的，除非你把它存放在某个地方;我不知道你怎么知道它是从2008年10月21日到2009年10月10日或25-10-2008到24-10-2009或21-10-1908到20-10-1909。
我在上面的部分（C）中确实认为你必须在某个地方有订阅的开始和结束日期，并且正如我在（D）中评论的那样，你应该能够在实际的续订请求交易时忽略以便计算下学期开始。
好的，现在，我将假设您确实没有存储过去订阅的订阅开始日期和结束日期。 （我觉得很难相信。）
以下是您问题的可能答案：
您确实拥有客户当前的到期日期（否则您将不知道何时开始前两个月续订窗口或三个月宽限期窗口）。因此，鉴于此当前订阅到期日期，您可以逐年倒退。通过这种方式，您将能够重建所有客户的过去订阅。
然而，这有一个问题，如果客户在宽限期内未能续订，那么新的订阅可能会从之前的时间间隔开始。 无论如何，仔细检查以确保没有可能的方法来确定订阅的开始和结束日期。我想你会在某个地方找到它们，并且应该能够将它们放入你的数据库中。
祝你好运。