Date comparison options

Hi’
I’ve got question around doing some date comparison. We currently doing project to monitor our various agents installed on the device, and one criteria is that they would like us to report all date fields in following format “YYYY-MM-DD HH:MM:SS”. I’ve found some relevance to do this (Thx Jason Walker).

Issue is we sometimes have to check if agent has been reporting recently and problem now is that the above date format is returned as “singular string”

Q: value of settings “_PG_AgentLastRun_AgentXXX” of client
A: 2022-09-15 10:10:48
T: 0.136 ms
I: singular string

I would like to do something like below to check agent has reported in last 24 hours or something similar
value of settings “_PG_AgentLastRun_AgentXXX” of client > now - 1*day
if it’s singular string that will not work

if I keep it in the time format then it works just fine
Q: value of settings “_PG_AgentLastRun_AgentXXX” of client
A: Thu, 15 Sep 2022 09:45:03 +0200
T: 1.402 ms
I: plural time

Looking for easy way to accomplish this, I could create parameter and find way to convert it back to singular time, but that’s to overcomplicated in my opinion also want to try and keep it standard across various agents when possible, as we also collect these settings as Properties that will be used for PowerBI Dashboard

any ideas/suggestion are welcome.

Your format is sortable, and you can compare strings, so use the same formatting to get ‘now - 24 * hour’ in a format you can compare

At its most basic, the two parts of the comparison will boil down to stringA > stringB

q: "2022-09-15 10:10:48" > "2022-09-14 12:20"
A: True
T: 0.027 ms
I: singular boolean

Generally, store BigFix time in things you want to compare in BigFix, and this external time format for things to compare externally. Sometimes store both?

Aka, “they wanted this format, now let their tool report on it”

Or, on the BES side, maybe examine “effective date of setting” instead of “value of setting”?

All, Thx for the info that’s really helpful.
@JasonWalker I’m using in some cases the “effective date of setting” but sometimes that’s not correct date we want to compare against, as the date when we write the setting is not always the date agent has reported to the backend, so it would give false positive.