1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

A bit of a complaint regarding @FileDate and @FileTime

Discussion in 'Support' started by mathewsdw, Nov 8, 2011.

  1. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    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...
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  3. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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!
     
  4. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,191
    Likes Received:
    11
    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!
     

Share This Page