what *IS* the logic behind Jamf's timestamps?!

The time stamps you see for policy run dates/times and inventory collection times are based on the time/clock in Universal Coordinated Time (UTC) of the server the webapp JAMF/JSS is running on itself. So if a recon/inventory is submitted when the webapp's underlying server says the time is 7:00AM Eastern (which is 4 hours behind UTC), then internally in the database the time is stamped as 11:00AM UTC. The way those time stamps are adjusted for display when you are in the admin page for the JSS is based on your time zone preferences under your account settings in the JSS. So, for that event, if your time zone setting is set to show the Pacific time zone, Pacific is 7 hours behind UTC, so it would show as 4:00AM.

If the underlying time on the Windows/Linux/macOS box that the JSS webapp is running on is wrong or its time zone is set inappropriately compared to what the clock says (e.g. the server is physically located in LA and its 9:00AM there but the server is set to 9:00AM with the wrong time zone of Eastern), then you will run into an issue where the time stamps are wrong because its converting the timestamp to UTC from Eastern when it should be converting to it from Pacific.

I know that was a lot of detail but hope that helps.

we're cloud hosted and i had to create a case to request that online services change our timezone from the default. i don't know if that does anything for you...in my situation the time displayed in the UI looked fine but the timestamps in the logs were way off.

For folks using Jamf Cloud, remember each Jamf admin or each person who accesses the Jamf server should set his or her own timezone preference. It defaults to Africa and UTC 00:00 time zone.

Log in to your Jamf Cloud instance and choose username in the upper right corner > Account Preferences > Language & Region tab. Set your personal time zone. This should make time stamps in Jamf make a little more sense to you.

While you're there, you may also want to click the Search Preferences tab and change all those "Exact Match" settings to "Contains" or "Starts With".

right - i had done that; and the timestamps in the UI were fine - but in logging.html the times were way off. that could only be changed by online services.

@talkingmoose sadly not 100% true. You can indeed set your timezone prefs in the user preferences but the moment you hit the export button you get a different timezone. I have to use a script to convert them so I can use them here in Japan.

@vanschip-gerard, not sure how times are affected with exported information and not sure if this is by design or a product issue. It doesn't appear in Jamf's published list of Product Issues.

If you can provide me exact steps to reproduce, I'm glad to test. Maybe we can get a case opened to get this addressed.

@talkingmoose It's very easy to replicate for me.
1. Set my time zone in "account preferences" to Tokyo which is +9.
2. Perform a search for all computers.
3. See the last checked in date, confirm its my Japanese time stamp (it is).
4. Hit export to CSV.
5. Open CSV file, find UTC dates.

@vanschip-gerard After doing some research, I understand your issue but it's likely going to take a feature request to change this behavior.

Stepping back from the issue a bit, it's not a product issue caused by a defect or a bug. Jamf Cloud servers are purposely set to UTC timezone. Jamf Pro admins may span time zones themselves, which is why each admin has his or her own preference setting for a time zone.

However, Advanced Computer Search and Advanced Mobile Device Search reports don't belong to a specific admin. Keep in mind these reports may be generated automatically on a schedule and emailed to users across time zones as well. No one time zone can accommodate all recipients across time zones.

As mentioned in the link above, Premium Jamf Cloud customers may request their server be set to something other than UTC, but that option won't be available to Standard Jamf Cloud customers.

Therefore, Jamf would need to add a feature to the Reports area to let admins specify a specific time zone. I found this feature request, but it could use some more up-votes. Configurable Time Zone for reports

Hope this helps explain things a little.

@talkingmoose is right; the server has to stay on UTC. Even Windows IIS logs activity in UTC.

I upvoted the feature request to have time zones in reports follow the local admin running them.