I know that DIR does it this way for compatibility with CMD.EXE. But CMD.EXE doesn't have a REGDIR command. There's no reason to do it wrong for compatibility with a hypothetical bug in a nonexistent command!
While we're at it: How about a U suboption to not localize times? And a S to display seconds? So, for example:
I see something even stranger. My own REGFIND.EXE has the option to show times (and only ONE routine to do so). When I compare it to REGDIR, some of the times agree and some disagree by an hour ... very odd.
I see something even stranger. My own REGFIND.EXE has the option to show times (and only ONE routine to do so). When I compare it to REGDIR, some of the times agree and some disagree by an hour ... very odd.
REGDIR gets it wrong if it's standard time and the timestamp is during Daylight Saving Time, or vice versa. Notice that the times where your two commands agree are in January — i.e. not DST, like today.
And, Charles, what are "/ts" and "/tsu"? They give me errors.
S and U are proposed suboptions for "show seconds" and "UTC times" respectively. REGDIR doesn't currently support them. I'm suggesting that some future version might.
REGDIR gets it wrong if it's standard time and the timestamp is during Daylight Saving Time, or vice versa. Notice that the times where your two commands agree are in January — i.e. not DST, like today.
S and U are proposed suboptions for "show seconds" and "UTC times" respectively. REGDIR doesn't currently support them. I'm suggesting that some future version might.
Actually, it's my REGFIND that's doing two different things. SystemTimeToTzSpecificLocalTime is applying the standard time or daylight saving time
correction depending on the date of the time.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.