Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

A bit of a complaint regarding @FileDate and @FileTime

May
855
0
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...
 
From: mathewsdw
Subject: [Support-t-3348] A bit of a complaint regarding @FileDate and @FileTime
...

This issue has been thoroughly discussed and debated in the forum over the years. Short summary:

1/ This is an NTFS artifact. All timestamps returned by MS programs (actual operating system software not included), e.g., Windows Explorer, Internet Explorer, CMD.EXE, etc. are in the terms of many users "screwed up". Rex Conn chose MS / CMD compatibility over correctness as the TC default. Some like it, some of us do not. Cannot satisfy all the people all the time.

2/ @fileage, @filedate and @filetime all have the option to return file timestamps in UTC, which does not vary with DST. This value can be used by your versioning system, as there will never be actually different timestamps which appear to be the same in local time, as can happen if you create a file in the one hour of "falling back".

3/ The plugin iso8601.dll from Charles Dye of the University of New Mexico has a function @filestamp which returns file timestamps based on the state of local DST at the time of the filestamp, not on what it is when you examine it. This function also behaves in the manner you desire.

As said, the tools are already availabe for you!
--
HTH, Steve
 
From: mathewsdw
Subject: [Support-t-3348] A bit of a complaint regarding @FileDate and @FileTime
...

This issue has been thoroughly discussed and debated in the forum over the years.

...

2/ @fileage, @filedate and @filetime all have the option to return file timestamps in UTC, which does not vary with DST.

...

3/ The plugin iso8601.dll from Charles Dye of the University of New Mexico has a function @filestamp which returns file timestamps based on the state of local DST at the time of the filestamp, not on what it is when you examine it. This function also behaves in the manner you desire.

...
--
HTH, Steve
Steve, despite what you say about "This issue has been thoroughly discussed and debated in the forum over the years", when I do a search, I don't come up with anything relevant at this time. If I'm doing something wrong (a definite possibility given my previously-mentioned disabilities) I don't know what that is

As far as "return file timestamps in UTC" goes, that is not an acceptable option for me because I want to see dates and times relative to whatever date and time I modified the file, for instance, in my time zone (I'm easily confused!).

I wasn't aware that Charles Dye's iso8601 plugin had that capability, and that is, in fact, the perfect solution. Thank you!
 
Matthew,

Unfortunately, this issue has been around in Windows since the very first
NTFS file system in Windows NT 3.1. One possible solution is to disable
DST on your PC and manually set the time on your computer. The down side
to doing that is the network time servers available on the Interwebs that
would normally set the time automatically on your PC won't work properly.
Your time would always be off by an hour during DST. Nonetheless, if you
are willing to manually set your computer's time, you can disable DST and
you won't see the local times change on your filesystem.

Another, not recommended solution, is to use FAT32 instead of NTFS for the
file system.

-Scott





Steve, despite what you say about "This issue has been thoroughly
discussed and debated in the forum over the years", when I do a search, I
don't come up with anything relevant at this time. If I'm doing something
wrong (a definite possibility given my previously-mentioned disabilities)
I don't know what that is

As far as "return file timestamps in UTC" goes, that is not an acceptable
option for me because I want to see dates and times relative to whatever
date and time I modified the file, for instance, in my time zone (I'm
easily confused!).

I wasn't aware that Charles Dye's iso8601 plugin had that capability, and
that is, in fact, the perfect solution. Thank you!
 

Similar threads

Back
Top