-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-09-01 at 10:35 -0400, James Knott wrote:
Carlos E. R. wrote:
And no, the correct procedure for Windows, since Vista, is to use UTC and tell Windows to also use UTC. This, again, is documented.
Are the file time stamps now in UTC? This has long been a problem with Windows. When you work across time zones, as I have done, you don't know what the true file time is.
Notice that the above recomendation is for the CMOS or hardware clock, not the system clock, which does not change. FAT stores local times, but NTFS uses some kind of UTC. I don't remember the details, but the wikipedia does: http://en.wikipedia.org/wiki/Ntfs#Universal_time +++··································· Universal time For historical reasons, the versions of Windows that do not support NTFS all keep time internally as local zone time, and therefore so do all file systems other than NTFS that are supported by current versions of Windows. However, Windows NT and its descendants keep internal timestamps as UTC and make the appropriate conversions for display purposes. Therefore, NTFS timestamps are in UTC. This means that when files are copied or moved between NTFS and non-NTFS partitions, the OS needs to convert timestamps on the fly. But if some files are moved when daylight saving time (DST) is in effect, and other files are moved when standard time is in effect, there can be some ambiguities in the conversions. As a result, especially shortly after one of the days on which local zone time changes, users may observe that some files have timestamps that are incorrect by one hour. Due to the differences in implementation of DST in different jurisdictions, this can result in a potential timestamp error of up to 4 hours in any given 12 months.[54] ···································++- - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIjVZgACgkQtTMYHG2NR9UPpQCcCjDsM07A+1IWbeb8Y70XHvYc iVwAn0EZcVkrPqcaBnSRJm5N/AXuI1ew =1nHk -----END PGP SIGNATURE-----