Thanks @agrawalravi90! After this change, would an “out of date” holiday’s file (e.g., a “YEAR 2018” file in use in 2019) cause the scheduler to behave as though all time is prime time?
The current documentation seems ambiguous on this and it seems like this is a good time to define the behavior. The current docs state both “If there is no YEAR line in the holidays file, primetime is in force at all times”, and “You must specify the year, otherwise primetime is in force at all times, and PBS will not recognize any holidays”. Emphasis mine. Does “the year” mean “the CURRENT year”. Is an out of date YEAR the same a NO YEAR?
I would actually like to see a completely commented out holidays file (include example configuration) on a default PBS installation. Since most sites do not actually have prime/non-prime queues or make meaningful scheduling policy differentiation between prime/non-prime time, what we do today causes unnecessary simulation work for the scheduler in terms of simulating the (inconsequential) daily transitions between prime/non-prime. The holidays we do include are U.S.-centric, and even then I believe most U.S. sites making serious use of prime/non-prime time likely modify this to match their company calendar.
Prior to the change proposed in this post it would have been incorrect to have an empty holidays file, but now it seems like a good idea. Thoughts from anyone on this?
P.S., If we did this I’d further propose issuing the current “The holiday file is out of date; please update it.” scheduler log message IFF the holidays file has an out of date “YEAR” line, not if there is NO “YEAR” line (logging that with a default-black holidays file would be annoying).