The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
Some of my users have shown me folders in Explorer have one time. The same folder in DOS CMD window are off by 1 hour.
DST happened recently so could be involved. I've googled and found mention that the timestamps are supposed to reflect that. But it should be consistent.
New files have identical timestamps, so it's just existing files.
Also, any workaround to get the DOS window to match timestamps? Scripts are feeding bad data.
I need an app that will automatically deliver a new BBBBBBBBaBB (beautiful blonde bimbo brandishing bountiful bobbing bare breasts and bodacious butt) every day.
John Simmons / outlaw programmer
Something else is a bit off I think. We just went off of daylight savings, so we gained an hour that we lost. So, if it was a result of the recent switch off of DST I'd think the command window would be showing a time of 11:40 AM, with explorer being one hour sooner. Which it's not, so it's gotta be something else.
I think this is what's happening then. I'm *guessing* the timestamp was saved in its real time (without a DST modifier) when DST was on. Presumably, the command window was smart enough to know DST is on and therefore adjusted the timestamps when shown on the fly. However, now that DST is off, it doesn't. Which is all fine and dandy except 9:40 didn't really exist back when that file was modified.
Any new changes, using the same logic, would be ok simply because DST off is off. So all good and the command processor doesn't need to be as smart as explorer.
To get around this, you're pretty much screwed bro. Best I think you can do in a batch file / script is just figure out if your date is within certain dates from when DST switches on and off and then account for it. It's hard coded. It's nasty. Not sure of anything else though.
And of course write a strongly written letter to MS for not storing timestamps in UTC.
Explorer is showing the timestamp using the DST settings which were in effect when the timestamp was created. Powershell does the same.
The venerable command prompt is showing the timestamp using the DST settings which are in effect now. And as Raymond said, fixing that minor display bug would carry too much risk of breaking something else.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
One of my vb programs checks to make sure all its files are up to date and then copies in updates using xcopy if necessary
I haven't noticed a pattern yet in the PCs it happens to but sometimes the program tries to update at every start. When I check I find the file is identical but the timestamp is one hour out so I manually copy using explorer and everything is happy again
This has been a problem for over a decade. I particularly see it with networked drives. If I have the same file on a local drive and on a networked drive, the file timestamps are off by one hour for 6 months of the year.
File timestamps should only be valid in GMT. Let the final software call an OS function to convert it to local time just before displaying the file time.
It's when the OS tries to be too smart that the problem arises. Some BIOS can automatically adjust for DST. But so can the OS. I believe the problem is when one drive is already automatically adjusted, but another drive is not. As in local drive versus networked drive.