RM9’s Date Last Edited field is actually a full date and time stamp, even though you only see the date part and not the time part in the RM9 user interface. In addition, the date and time stamp is recorded as a UTC date and time (also known as Zulu time or GMT or Greenwich Mean Time). I understand the logic for doing it that way. For example, I have a pilot’s license and we always fly using UTC time. It totally avoids issues with time zones and standard time vs. savings time (or summer time, if you prefer)…
But it means that changes I’m making in RM9 as we speak are showing up as 10 May 2023 even though in my U. S. Eastern Time Zone it is still 9 May 2023. I’m hard pressed to come up with a different or better way to do it, but it certainly is confusing.
Also, I’m making the same changes in RM7 and in RM9 and comparing the results. For my real data - names and places and dates for events and things like that - RM7 and RM9 are matching just fine. But for the Date Last Edited field, RM7 is still recording changes as 9 May 2023 and so the change date in RM9 doesn’t match the change date in RM7. I’m quite sure that the RM9 design didn’t anticipate anybody entering the same data into RM7 and RM9 at more or less the same time and then noticing the Date Last Edited Fields were different because RM7 is using local time and RM9 is using UTC time.
Quite often, when I’m going to meet a few friends for drinks, one of them will never show up. It turns out that he’s on UTC instead of local time.
I can’t imagine a valid reason for recording a timestamp in anything but your local time. Imagine if Windows recorded the file update timestamps in UTC or your email service recorded your email dates in UTC.
Ii think it’s pretty much mandatory that computers record dates and times as UTC. I think they mostly do.
For example, I used to travel a great deal between two time zones, using my computer in each time zone. It wouldn’t do under those circumstances to have a file created at a time that was still in my local future. Or more generally, any kind of sync type of operations I might need to do between two versions of the same file would really need to be done using UTC times so that me traveling between time zones would not mess things up.
For another example, UTC times are essential for collaboration between multiple users who may be in different time zones if that collaboration involves the syncing of timestamps.
The trick is that for the most part computers should display local times rather than UTC times. In the aviation example I gave, airline passengers will be flying on local times, but in the cockpits the pilots will be working on UTC time. I’m only a private pilot, but even private pilots fly on UTC time and air traffic control operates on UTC time. That being said, I would hate to have to deal with UTC times in computer interfaces. Except that RM9 is doing it that way - not a good thing.