- May 24, 2010
As everybody well knows, there was a time change this weekend for most of the country to change from "Daylight Savings Time" to "standard time". Well, it turns out that that had an unexpected and (to me) somewhat unacceptable side-effect, and that is that the last-modification times (and possibly dates) of files that were last modified before the time change were also effectively "modified" after the time change, and this has a very unacceptable side-effect for me. Without going into great detail, I use the last-modification times (and dates) for "versioning" purposes, and having those times (and possibly dates) effectively changing without anything else about the file changing causes me significant problems because it throws my "versioning" system "all out of whack", as the saying goes. I'm not quite sure what the best way to "handle" this would be; having file create, last-modified, and last-accessed times recorded and/or displayed in "standard time" at all times could certainly cause confusion if the current time/date is within "Daylight Savings Time", but, again, having these times (and possibly dates) change without the file being changed in any way is also problem. The best "solution" I can suggest is to have an optional "standard time" parameter for the @FileTime and @FileDate functions that causes the function to examine the file's date and time to see if it is set to a time/date that is within the period where Daylight Savings Time was in effect, and therefore convert that time to "Standard Time" for reporting purposes. This would be very similar to the existing "u" (UTC) option (which I am almost certain must also aware of the current time zone and whether or not Daylight Savings Time is in effect); after all, Windows 7 at least (and I'd be very surprised if it wasn't true for Windows XP and probably earlier Windows versions, but since I haven't used any of them for a long time I can't be sure about that) is completely "aware" of the time zone you are in and whether or not Daylight Savings Time is in effect, and so is TCMD/TCC as a whole, so to speak, given that there is the "%_DST" "internal" variable. Just an idea, unless someone has a better idea...