Store lastComplianceCheck date string as a regularised value

[modestindustries]

Problem to solve

Right now, the date string appears to be stored as a localised value, sensitive to language and region settings on the Mac. This means that using the date string elsewhere is problematic. If you are, for example, trying to calculate the number of hours or days since the last scan, your code must anticipate all possible date string formats, when converting to epoch seconds to perform date math.

Intended users

Admins who need to use this data for additional checks or reporting.

Further details

Storing the date string in a reliable format allows for predictable re-use of the information.

Proposal

Allow control over the date string format, or adopt an international standard format, if one exists.

Documentation

We're seeing date returned in at least three formats, which we suspect are related to localisation settings on the Mac.

Fri 31 May 2024 11:30:32 EDT
Fri May 31 11:30:32 EDT 2024
Fri May 31 11:30:32 -5 2024

Testing

Would require anyone using this key to check their code in order to validate that the date string still works.

What does success look like, and how can we measure that?

Date string can be defined, or relied on to be in a standard format.

Links / references

[brodjieski]

It might make sense to store this as a standardized format... either local time, or maybe UTC?

❯ date +"%Y-%m-%d %H:%M:%S"
2024-07-16 08:12:34
❯ date -u +"%Y-%m-%d %H:%M:%S%z"
2024-07-16 12:12:43+0000

Any thoughts or preferences?

[modestindustries]

I might consider adopting the ISO 8601 standard: https://en.wikipedia.org/wiki/ISO_8601 Although I can see a strong case for using the local time of the device. If the latter, then we need a UTC offset for the timezone (not the timezone name) in the string; it’s faster to interpret, provided you know the timezone of the device. Perhaps a flag, —tz, where possible values are: - local (default, if —tz is omitted, use the localized date string on the Mac, which is currently the way it works) - utc (disregard localization, string in UTC, so 2024-07-17T00:19:18Z) - utc_offset (disregard localization, apart from timezone, string expressed with UTC timezone offset, so 2024-07-16T12:19:18−12:00 ) Open to being wrong about this.

…

On Jul 16, 2024, at 8:15 AM, Dan Brodjieski ***@***.***> wrote: It might make sense to store this as a standardized format... either local time, or maybe UTC? ❯ date +"%Y-%m-%d %H:%M:%S" 2024-07-16 08:12:34 ❯ date -u +"%Y-%m-%d %H:%M:%S%z" 2024-07-16 12:12:43+0000 Any thoughts or preferences? — Reply to this email directly, view it on GitHub <#405 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWXUS4KC6WXV6KMVN32NFTZMUFFTAVCNFSM6AAAAABKH2EN2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQG42DAOBUGY>. You are receiving this because you authored the thread.

-- Andrew Ball ***@***.***

[tuxudo]

I am in favor of this change. It does cause problems for parsing the data/time with the macos_security_compliance MunkiReport module: tuxudo/macos_security_compliance#2

No real preference on how it would be stored, so long as it is standardized across locales

[georgalis]

I highly recommend storing the date in UNIX seconds format. This format is easily processed and converted to human readable locale for reports. Integer seconds will simplify automated checks; for example if the difference with current time is N seconds or greater, then process a new compliance check. Another simplified case is rendering timestamps for an alternate timezone; for example, creating a compliance report for a west coast machine, that indicates successful compliance check with appropriate timestamp, alongside an east coast locale timestamp, that is used for publishing a particular STIG.