Store lastComplianceCheck date string as a regularised value #91

New Issue

michael · 2026-01-19T18:29:12Z

michael commented

2026-01-19 18:29:12 +00:00

Originally created by @modestindustries on GitHub.

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

Originally created by @modestindustries on GitHub. ### 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

michael closed this issue

2026-01-19 18:29:12 +00:00

michael commented

2026-01-19 18:29:13 +00:00

@tuxudo commented on GitHub:

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

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

@tuxudo commented on GitHub: I am in favor of this change. It does cause problems for parsing the data/time with the `macos_security_compliance` MunkiReport module: https://github.com/tuxudo/macos_security_compliance/issues/2 No real preference on how it would be stored, so long as it is standardized across locales

michael commented

2026-01-19 18:29:13 +00:00

@brodjieski commented on GitHub:

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?

@brodjieski commented on GitHub: 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?

michael commented

2026-01-19 18:29:13 +00:00

@georgalis commented on GitHub:

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.

@georgalis commented on GitHub: 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.

michael commented

2026-01-19 18:29:13 +00:00

@modestindustries commented on GitHub:

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 https://github.com/usnistgov/macos_security/issues/405#issuecomment-2230740846, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWXUS4KC6WXV6KMVN32NFTZMUFFTAVCNFSM6AAAAABKH2EN2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQG42DAOBUGY.
You are receiving this because you authored the thread.

--
Andrew Ball
@.***

@modestindustries commented on GitHub: 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 <https://github.com/usnistgov/macos_security/issues/405#issuecomment-2230740846>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWXUS4KC6WXV6KMVN32NFTZMUFFTAVCNFSM6AAAAABKH2EN2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQG42DAOBUGY>. > You are receiving this because you authored the thread. > -- Andrew Ball ***@***.***

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: usnistgov/macos_security#91