Time Management of jobs running over new year

[mathisloevenich]

HTCondor Logs contain Events with a timestamp in this form:

07/11 20:40:03

... obviously missing the year

The htcondor python bindings do actually assign a year to each event but I recognized that this is just the current year and is not derived by f.e. the creation date of the logfile.

This makes it hard to read old log files older than one year, cause the year value is then ambigious.
Probably it's not even possible within our cluster to run jobs over new year or longer than one year,
BUT this tool should not care about our ways of working or our infrastructure.

I don't know how important this is or if there will be cases where this matters but still I've managed to
check if a job runs over new year.
This makes it at least a bit less pain to keep track.

However it's not possible whatsoever to solve this issue, as the information about the year is lost and not available, only if it's tracked from the creation date of a log-file, which is also not 100% trustworthy.

What do you think ? Am I missing something ?

[mathisloevenich]

To quote @aqw: Jobs can run longer than one year, but it's unlikely and if the information is lost, there is no way to solve this issue.

So if an end date is before the start date, then assume it rolled-over the year boundary

That's the current state and half-way solution to this problem.

[mathisloevenich]

Do everything the same as before, with two changes:

1. protect against the leap-year loophole. Comment appropriately in the code.
2. when printing the date to the user, never display the year, since you don't actually know

[mathisloevenich]

It's not possible to solve this issue, because htcondor is transforming leap-year time-stamps like 02/29 20:39:51
into 2021-03-01 20:39:51

[mathisloevenich]

So it depends on htcondor.