OK, found it. Here's the commit that changed the behaviour:
https://repo.or.cz/jimtcl.git/commitdiff/f85a6e7c5a6387d721f19335984a838863237131
Specifically, these bits are of interest:
Code:
static int clock_cmd_scan(Jim_Interp *interp, int argc, Jim_Obj *const *argv)
{
char *pt;
struct tm tm;
- time_t now = time(0);
+ /*time_t now = time(NULL);*/
and
- /* Initialise with the current date/time */
- localtime_r(&now, &tm);
+ /* Set unspecified fields to 0, e.g. HH:MM becomes 00:00 */
+ memset(&tm, 0, sizeof(tm));
+ /* But this is 1-based */
+ tm.tm_mday = 1;
Docs. for strptime(), which is called immediately afterwards, say:
In principle, this function does not initialize tm but stores only the values specified. This means that tm should be initialized before the call.
This is especially important if you are going to feed the result back into mktime(), which is exactly what happens.
But is it a bug in Jim or not? That is debatable.
The documentation is hardly explicit about what it's supposed to do.
IMO, you are somewhat abusing
clock scan and getting it to do something it probably wasn't really designed to do, and the result you wanted was just a side-effect that happened to work at some points in time, and now doesn't.
My solution above would appear to be the correct one regardless.
I expect there might be a DST problem here though, but I think there always might have been?
(The Jim docs. don't even mention the -gmt option on
clock scan).
Probably also worth reviewing these:
html/xepg/index.jim: set tt [clock scan \
lib/rsv.class: set stamp [clock scan $spaced -format "%Y %m %d %H %M %S"]
lib/rsv.class: set today [clock scan 00:00:00 -format "%T"]
