Automating Dates

[PaigeMiller]

The problem with the solution from @mkeintz is that it turns dates into character variables, which sort alphabetically, and so then you have to resort to adding in a sequence number at the start to force it to sort chronologically. The '25: ' or similar at the start is meaningless; no one knows what the 25 means but it takes up space and it confuses people.

If you use custom formats via PROC FCMP, or even the simple MONYY. format, then the values can be sorted chronologically, and thus it is not only simpler, but easier for humans to read.

[mkeintz]

---

@PaigeMiller wrote:

The problem with the solution from @mkeintz is that it turns dates into character variables, which sort alphabetically, and so then you have to resort to adding in a sequence number at the start to force it to sort chronologically. The '25: ' or similar at the start is meaningless; no one knows what the 25 means but it takes up space and it confuses people.

If you use custom formats via PROC FCMP, or even the simple MONYY. format, then the values can be sorted chronologically, and thus it is not only simpler, but easier for humans to read.

---

@PaigeMiller 's criticism of the text variable shortcomings is right of course, but in this case not until July 2028, when the alphabetic sort will fail to replicate chronological order..

Until then, I can hide behind the OP's literal request, because each salesperiod text value starts with a two-digit (z2. format) enumerated date range (01 for 06apr2020-05may2020, etc.).  This will replicate date order until range number 100 occurs - (July 2028 I think) when three digits will be needed.

I guess one could extend my solution by using Z3. format (and modifying accordingly the VALUE statement for the irregular historic date ranges).  That would provide another 900 months (July 2104).  So there can be wiggle room.