Jester3141 wrote:I wonder if this is a problem where the database field backing the expiration date is a string and it works/doesnt't work based on the format that the date was put in?
I really doubt that, since various operations clearly work in a way that there must be an understanding of the actual date value of that field.
But I just did some more research, which suggests an alternate theory. I sorted the list by the "Expires" column and found that (with minor exceptions I'll mention later) all the Expired recommends have expiration dates through a cutoff date, and then all the Expiring recommends are listed, followed by the Active recommends.
Two interesting points that become apparent when you sort by "Expires":
- The boundary date between the Expired and Expiring sections of the sorted list varies from ward to ward. For one ward it is in early 2008, and for another it is in early 2009; for yet another it is in early 2010. That's really strange. At first I thought that the cutoff date might just be off by two years (meaning that a programmer misinterpreted the "Expires" date as the "Issued" date). But that can't be the case.
- In most wards, there are one or two outliers -- recommends listed as Expired that are significantly later than that boundary date. I can see no pattern in these; some are listed for months in which other members have Expiring recommends. But there are very few of these (8 in my whole stake) and all but one are in March or April 2013.
But in any case, it doesn't work correctly, so thank you for submitting feedback.