New course term validation method

[azharichenko]

A simple change that makes testing terms really easy. This came from thinking about how the term code is structured and it's very simple.

---

Take the current term code for fall of 2017 2181. This code seems weird but it's simply a representation of date the term ends, which would be January 2018. So the 218 is the year and the 1 is the month the term ends. Making it simple that if the term code starts with 2 and ends with 1, 4, or 7 then we can assume quickly it could be a valid term.

[timparenti]

This code seems weird but it's simply a representation of date the term ends

Just a note that while this assertion is functionally close/approximate, it is factually incorrect and should not be used as a general assumption. Formally speaking, fall term ends in December, spring term (very) occasionally ends in May (though only 1 May), and summer term ends in early August.

Historically, term codes were of the form 98-1, 98-2, and 98-3, referring to the three terms in Fiscal/Academic Year 1998 (that is, 1997–1998). Upon transitioning to PeopleSoft, a prefix digit was added as a de facto century indicator, and the suffixes were spaced out to 1, 4, and 7 to allow for more inventive course term offerings. There are, in fact, some artifacts of winter/January and spring/May "sessions" ending in 2 and 5, for example, but they are not currently used nor have been for a while.

Presumably if these systems are still around in ~80 years, the century ID will become 3:

2997 - Summer 2099 3001 - Fall 2099 3004 - Spring 2100

[RitwikGupta]

Wait, @azharichenko, I had a regex previously there checking the exact same thing. You might want to just pull that regex back up since it was a simple two lines of code. Also, everything Tim said is correct, but the chances of any of this being around in 80 years is ~0%, so this is fine for these purposes.

[timparenti]

So, two things:

• In general, pull requests should be cleanly branched off of the latest main development branch, or rebased onto the same. There are several commits here that appear to just be several months of merges from upstream, which makes it much harder to figure out what's actually changed, especially when going back to view the merge later.
• I think the regex is significantly cleaner for determining valid term codes (at least within the current century), but there appear to be some other unrelated changes that might be good here. That said, the regex should really be more like 2\d\d[147].