Generic display of Spotlight Metadata for file(s)

[Nigel_Garvey]

@DJ Bazzie Wazzie

Well the difference between the code above and previous post (using date -jnu) is that the first example convert the time back to GMT while the example in this post will only use local time. You only need GMT code when global time is important. For instance: I have a server and the file is modified locally (in Netherlands; CET) and two hours later someone edits a similar file in the US. When you compare the dates using the handler in this post, results that the file (newer) saved in the US will be considered as an older, earlier, saved version. When you use the handler using the date -jnu options the results will be correct because both dates will be coerced to GMT times and therefore the file from the US will be considered last changed.

Hmm. I’m pretty sure that files saved two hours apart in real time but in different time zones (assuming computers with correctly set times) will have creation/modification dates which are two hours apart when viewed together on a single machine ” and in accordance with the time zone of that machine.

But I seem to have been misled by the time-zone offsets returned in the metadata here. They don’t reflect the zones in which the files were created or modified, but are entirely to do with the current machine. Change the machine’s time zone and the time zone displacements in the metadata change too. There’s no point in transposing the date/times to the local time zone because they’re always in it anyway! Makes my script even simpler! :rolleyes:

An interesting learning experience, though.

[McUsr]

@Nigel Garvey

@DJ Bazzie Wazzie

Well the difference between the code above and previous post (using date -jnu) is that the first example convert the time back to GMT while the example in this post will only use local time. You only need GMT code when global time is important. For instance: I have a server and the file is modified locally (in Netherlands; CET) and two hours later someone edits a similar file in the US. When you compare the dates using the handler in this post, results that the file (newer) saved in the US will be considered as an older, earlier, saved version. When you use the handler using the date -jnu options the results will be correct because both dates will be coerced to GMT times and therefore the file from the US will be considered last changed.

Hmm. I’m pretty sure that files saved two hours apart in real time but in different time zones (assuming computers with correctly set times) will have creation/modification dates which are two hours apart when viewed together on a single machine ” and in accordance with the time zone of that machine.

As I have understood it, me totally being the layman in this, I agree with that.

@Nigel Garvey

But I seem to have been misled by the time-zone offsets returned in the metadata here. They don’t reflect the zones in which the files were created or modified, but are entirely to do with the current machine. Change the machine’s time zone and the time zone displacements in the metadata change too. There’s no point in transposing the date/times to the local time zone because they’re always in it anyway! Makes my script even simpler! :rolleyes:

An interesting learning experience, though.

Here I see one caveat really, this nitpicking, but how about if you access files remotely, what will the date time representation of the files then be, my guess is that the files will be represented as they were on the remote machine. Just for the sake of nitpicking, -at the moment!

[DJ_Bazzie_Wazzie]

Nigel, the server was a bad/poor example, what I meant is that the local time hasn’t changed, the time zone will fix the presentation but not the actual (local time) data. A better example would be storing these dates into a database server.