In src/meta/meta_ckpt.c, _wt_meta_read_checkpoint_snapshot (line 1782) and __meta_retrieve_timestamp (line 1835) retrieve the optional checkpoint wall-clock time with WT_ERR_NOTFOUND_OK(_wt_config_getones(session, sys_config, …, &cval), false) but then unconditionally call __ckpt_parse_time(session, &cval, ckpttime) regardless of whether the key was found. When checkpoint_time (or time) is absent, __wt_config_getones returns WT_NOTFOUND and leaves cval unchanged, retaining data from the preceding configuration lookup (e.g. snapshot_max). __ckpt_parse_time (meta_ckpt.c line 224) then parses that stale cval string via sscanf and silently stores the wrong value into *ckpttime. In a metadata string such as "snapshot_min=10,snapshot_max=20,snapshot_count=0" without a checkpoint_time key, *ckpttime receives 20 instead of 0. 

For Reproduce;
I added catch2 unit test (test_checkpoint_time.cpp) reproduces the issue and verifies the fix. (I added before/after outputs added on JIRA). 
In a scenario where checkpoint metadata contains snapshot fields without a checkpoint_time key, __wt_meta_read_checkpoint_snapshot without the fix causes __ckpt_parse_time to parse the stale snapshot_max configuration value into *ckpttime, causing REQUIRE(ckpt_time == 0) to fail (20 == 0).
With the fix, __ckpt_parse_time is only invoked when __wt_config_getones finds the key (ret == 0), and *ckpttime correctly remains 0.

Proposed Fix;
The fix stores the return value of __wt_config_getones in both __wt_meta_read_checkpoint_snapshot (meta_ckpt.c line 1782) and __meta_retrieve_timestamp (meta_ckpt.c line 1835), only invoking __ckpt_parse_time when the key is present (ret == 0), and then ignoring WT_NOTFOUND via WT_ERR_NOTFOUND_OK(ret, false).