|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Public Thank You To MicrosoftI wish to thank Microsoft for changing all the dates on my PC so that the
Pen Drive I use to carry around applications to and from my laptop are now one hour out of sync and my compare utility says they are not the same. OK they are not the same because the time has shifted. Maybe I should have two pen drives, one for standard time and one for daylight 'slavings' time. Joy! Multiposted to give some people a reason to complain. Your system changed for Daylight Savings Time because YOU elected to have it
do that. To turn it off (so that you will have to manually adjust the time when the daylight/standard time shifts occur), right click the time in the System Tray, select the "Date/Time Properties" item in the popup menu that appears, select the "Date and Time" tab on the dialog box that appears, click the "Change time zone" button and uncheck the "Automatically adjust clock for Daylight Saving Time" checkbox. -- Show quoteHide quoteRick (MVP - Excel) "Lorin" <lor***@hotmail.com> wrote in message news:F6101FC8-1ED1-4ADB-AA25-415EFF9632D4@microsoft.com... >I wish to thank Microsoft for changing all the dates on my PC so that the >Pen Drive I use to carry around applications to and from my laptop are now >one hour out of sync and my compare utility says they are not the same. OK >they are not the same because the time has shifted. Maybe I should have >two pen drives, one for standard time and one for daylight 'slavings' time. >Joy! > Multiposted to give some people a reason to complain. > That is no excuse for MS to change the file times on my PC.
Little brother at work again. Show quoteHide quote "Rick Rothstein" wrote: > Your system changed for Daylight Savings Time because YOU elected to have it > do that. To turn it off (so that you will have to manually adjust the time > when the daylight/standard time shifts occur), right click the time in the > System Tray, select the "Date/Time Properties" item in the popup menu that > appears, select the "Date and Time" tab on the dialog box that appears, > click the "Change time zone" button and uncheck the "Automatically adjust > clock for Daylight Saving Time" checkbox. > > -- > Rick (MVP - Excel) > > > "Lorin" <lor***@hotmail.com> wrote in message > news:F6101FC8-1ED1-4ADB-AA25-415EFF9632D4@microsoft.com... > >I wish to thank Microsoft for changing all the dates on my PC so that the > >Pen Drive I use to carry around applications to and from my laptop are now > >one hour out of sync and my compare utility says they are not the same. OK > >they are not the same because the time has shifted. Maybe I should have > >two pen drives, one for standard time and one for daylight 'slavings' time. > >Joy! > > Multiposted to give some people a reason to complain. > > > > You're really not THAT naive, are you?
-- Show quoteHide quoteMike "Lorin" <Lo***@discussions.microsoft.com> wrote in message news:79F17116-5081-49A8-8F60-5F36E3981AF5@microsoft.com... > That is no excuse for MS to change the file times on my PC. > Little brother at work again. > > "Rick Rothstein" wrote: > >> Your system changed for Daylight Savings Time because YOU elected to have >> it >> do that. To turn it off (so that you will have to manually adjust the >> time >> when the daylight/standard time shifts occur), right click the time in >> the >> System Tray, select the "Date/Time Properties" item in the popup menu >> that >> appears, select the "Date and Time" tab on the dialog box that appears, >> click the "Change time zone" button and uncheck the "Automatically adjust >> clock for Daylight Saving Time" checkbox. >> >> -- >> Rick (MVP - Excel) >> >> >> "Lorin" <lor***@hotmail.com> wrote in message >> news:F6101FC8-1ED1-4ADB-AA25-415EFF9632D4@microsoft.com... >> >I wish to thank Microsoft for changing all the dates on my PC so that >> >the >> >Pen Drive I use to carry around applications to and from my laptop are >> >now >> >one hour out of sync and my compare utility says they are not the same. >> >OK >> >they are not the same because the time has shifted. Maybe I should have >> >two pen drives, one for standard time and one for daylight 'slavings' >> >time. >> >Joy! >> > Multiposted to give some people a reason to complain. >> > >> >> > "MikeD" <nob***@nowhere.edu> wrote in message You are being nice by using naive.news:OFFizIEoJHA.3572@TK2MSFTNGP05.phx.gbl... > You're really not THAT naive, are you? > > "Lorin" <lor***@hotmail.com> wrote in message You can't blame Microsoft for this. Would you rather your PC's clock be news:F6101FC8-1ED1-4ADB-AA25-415EFF9632D4@microsoft.com... >I wish to thank Microsoft for changing all the dates on my PC so that the >Pen Drive I use to carry around applications to and from my laptop are now >one hour out of sync and my compare utility says they are not the same. OK >they are not the same because the time has shifted. Maybe I should have >two pen drives, one for standard time and one for daylight 'slavings' time. >Joy! incorrect? It amazes me the number of idiots that'll use any lame excuse they can to find something to blame on Microsoft. I'm not saying MS is not without blame on many things, but be reasonable! -- Mike MikeD wrote:
> No defense of the paranoid claims of the OP, but...> It amazes me the number of idiots that'll use any lame excuse they > can to find something to blame on Microsoft. I'm not saying MS is > not without blame on many things, but be reasonable! It is a bit lame that "local file time" changes for all existing files when DST changes. The underlying time is kept in UTC and only rendered for display in the local TZ. These files did not change, nor did their time stamps -- so why should they appear to have? You could certainly make a case that it's a design flaw. A smarter file compare utility might optionally use the system file time, not the displayed local file time, when deciding if a file had changed. That would make it immune to DST. As it is, I'll be going through the same thing when I next use RoboCopy to sync my incremental backups. Tens of gigabytes of files will get copied for no good reason -- just as they were a few months ago. > It is a bit lame that "local file time" changes for all I did not test it, but why should a file's date and time > existing files > when DST changes. The underlying time is kept in UTC and > only rendered > for display in the local TZ. These files did not change, > nor did their > time stamps -- so why should they appear to have? You > could certainly > make a case that it's a design flaw. change after DST changes? A file created at 6 o'clock before DST change has still to be reported as 6 o'clock when DST has changed. DST was explicitely made to address 6 o'clock for different sun positions in winter and summer. Therefore, if a file created/accessed before DST change would show another time afterwards would be a fatal error. Claus Centrino wrote:
> Jim Mack wrote... Then you should test it. It's easy. It may affect only NTFS file>> It is a bit lame that "local file time" changes for all >> existing files when DST changes. > > I did not test it... systems. > ...but why should a file's date and time It doesn't, at least not the actual file time stamp. What does change> change after DST changes? is the reported time. If backup and compare utilities relied on the true time stamp (and maybe some do), the problem wouldn't exist.
Show quote
Hide quote
"Claus Centrino" <c***@sofort-mail.de> wrote in news:gp30qo$ldd$1 Yeat another flaw in Windows. The system SHOULD look to see if the file @online.de: >> It is a bit lame that "local file time" changes for all >> existing files >> when DST changes. The underlying time is kept in UTC and >> only rendered >> for display in the local TZ. These files did not change, >> nor did their >> time stamps -- so why should they appear to have? You >> could certainly >> make a case that it's a design flaw. > > I did not test it, but why should a file's date and time > change after DST changes? > > A file created at 6 o'clock before DST change has still to > be reported as 6 o'clock when DST has changed. > DST was explicitely made to address 6 o'clock for different > sun positions in winter and summer. Therefore, if a file > created/accessed before DST change would show another time > afterwards would be a fatal error. was created/modified/accessed during DST time or not, and if the created/modified/accessed stamp was NOT during DST, it should not show as DST. DanS wrote:
Show quoteHide quote > "Claus Centrino" <c***@sofort-mail.de> wrote in news:gp30qo$ldd$1 It is nice not to have that problem in Arizona, as we don't use daylight > @online.de: > >>> It is a bit lame that "local file time" changes for all >>> existing files >>> when DST changes. The underlying time is kept in UTC and >>> only rendered >>> for display in the local TZ. These files did not change, >>> nor did their >>> time stamps -- so why should they appear to have? You >>> could certainly >>> make a case that it's a design flaw. >> >> I did not test it, but why should a file's date and time >> change after DST changes? >> >> A file created at 6 o'clock before DST change has still to >> be reported as 6 o'clock when DST has changed. >> DST was explicitely made to address 6 o'clock for different >> sun positions in winter and summer. Therefore, if a file >> created/accessed before DST change would show another time >> afterwards would be a fatal error. > > Yeat another flaw in Windows. The system SHOULD look to see if the > file was created/modified/accessed during DST time or not, and if the > created/modified/accessed stamp was NOT during DST, it should not > show as DST. saving. :-) -- Norm Don't blame me, my programming is self-taught and my teacher was not very experienced. :-) normfowler_don't u***@hotmail.com Jim Mack wrote:
> As it is, I'll be going through the same thing when I next use No way? RoboCopy is too dumb to use the actual timestamp, and is localizing it > RoboCopy to sync my incremental backups. Tens of gigabytes of files > will get copied for no good reason -- just as they were a few months > ago. first?!? <groan> Karl E. Peterson wrote:
> Jim Mack wrote: As I briefly suggested in another post, it's possible that this is an>> As it is, I'll be going through the same thing when I next use >> RoboCopy to sync my incremental backups. Tens of gigabytes of files >> will get copied for no good reason -- just as they were a few >> months ago. > > No way? RoboCopy is too dumb to use the actual timestamp, and is > localizing it first?!? <groan> NTFS issue, or rather an NTFS vs FAT32 issue. The backup drives are formatted FAT32, but the rest of the system uses NTFS. I know that NTFS uses UTC stamps, but I don't know if FAT32 does -- probably not. That would mean there's currently no way to avoid the problem. FAT32 has been preferred for portable drives because it's universally supported. But I suppose by now NTFS is everywhere too. I never tried formatting a thumb drive as NTFS -- most of them come preformatted FAT32 -- and that's the scenario that causes the most pain, because those things are so slow. It can take hours to resync an 8GB thumb, and it happens twice a year. Sounds like an experiment that needs doing... Jim Mack wrote:
Show quoteHide quote > Karl E. Peterson wrote: Yeah, that's my exact way of thinking, too. Pretty sure FAT32 doesn't.>> Jim Mack wrote: >>> As it is, I'll be going through the same thing when I next use >>> RoboCopy to sync my incremental backups. Tens of gigabytes of files >>> will get copied for no good reason -- just as they were a few >>> months ago. >> >> No way? RoboCopy is too dumb to use the actual timestamp, and is >> localizing it first?!? <groan> > > As I briefly suggested in another post, it's possible that this is an > NTFS issue, or rather an NTFS vs FAT32 issue. > > The backup drives are formatted FAT32, but the rest of the system uses > NTFS. I know that NTFS uses UTC stamps, but I don't know if FAT32 > does -- probably not. > That would mean there's currently no way to I think NTFS is available anywhere I'd want to plug something in. I know I > avoid the problem. FAT32 has been preferred for portable drives > because it's universally supported. But I suppose by now NTFS is > everywhere too. reformatted the last flash drive I got to use NTFS. > I never tried formatting a thumb drive as NTFS -- most of them come Lemme know how it goes. :-)> preformatted FAT32 -- and that's the scenario that causes the most > pain, because those things are so slow. It can take hours to resync an > 8GB thumb, and it happens twice a year. Sounds like an experiment that > needs doing... Karl E. Peterson wrote:
> Jim Mack wrote: Experiment complete.> >> I never tried formatting a thumb drive as NTFS -- most of them come >> preformatted FAT32 -- and that's the scenario that causes the most >> pain, because those things are so slow. It can take hours to >> resync an 8GB thumb, and it happens twice a year. Sounds like an >> experiment that needs doing... > > Lemme know how it goes. :-) I had three identical FAT32 4GB thumb drives. all backing up the same single branch of a development drive using RoboCopy /MIR. The last backups had occurred before the DST switch. FYI, I'm nominally at GMT -05:00, -4 when DST. I ran the RoboCopy script against an unmodified thumb, and it took 2.5 hours, copying every single file over again. This is the behavior we've been bemoaning. For the second drive, I ran CONVERT to make it an NTFS volume, and applied the same /MIR. Result: 2.5 hours. Then I set my TZ to make my effective offset -05:00 again (CDT). I ran CONVERT against the last thumb, then switched the TZ back to EDT. So now I effectively have what I would have, if I'd done the CONVERT before the DST switch. Ran the same script -- fifteen seconds. So clearly FAT32 doesn't use UTC, and between drives that use NTFS, the time change is not an issue. RoboCopy is doing the best it can with the data it has. As long as you don't plan to use your USB sticks in an environment that doesn't support whatever version of NTFS is on your main box, reformatting to NTFS seems to be a win. I know I'm sold. Jim Mack wrote:
Show quoteHide quote > Karl E. Peterson wrote: And I feel *so* vindicated! :-)>> Jim Mack wrote: >> >>> I never tried formatting a thumb drive as NTFS -- most of them come >>> preformatted FAT32 -- and that's the scenario that causes the most >>> pain, because those things are so slow. It can take hours to >>> resync an 8GB thumb, and it happens twice a year. Sounds like an >>> experiment that needs doing... >> >> Lemme know how it goes. :-) > > Experiment complete. > > I had three identical FAT32 4GB thumb drives. all backing up the same > single branch of a development drive using RoboCopy /MIR. The last > backups had occurred before the DST switch. FYI, I'm nominally at > GMT -05:00, -4 when DST. > > I ran the RoboCopy script against an unmodified thumb, and it took 2.5 > hours, copying every single file over again. This is the behavior > we've been bemoaning. > > For the second drive, I ran CONVERT to make it an NTFS volume, and > applied the same /MIR. Result: 2.5 hours. > > Then I set my TZ to make my effective offset -05:00 again (CDT). I ran > CONVERT against the last thumb, then switched the TZ back to EDT. So > now I effectively have what I would have, if I'd done the CONVERT > before the DST switch. > > Ran the same script -- fifteen seconds. So clearly FAT32 doesn't use > UTC, and between drives that use NTFS, the time change is not an > issue. RoboCopy is doing the best it can with the data it has. > > As long as you don't plan to use your USB sticks in an environment > that doesn't support whatever version of NTFS is on your main box, > reformatting to NTFS seems to be a win. I know I'm sold. Excellent. The 8Gb stick I converted to NTFS is primarily just for this very purpose -- a code backup. Nice to know I got one right. "Jim Mack" <jmack@mdxi.nospam.com> wrote in message <g>news:Op$4k6EoJHA.5420@TK2MSFTNGP04.phx.gbl... > MikeD wrote: >> >> It amazes me the number of idiots that'll use any lame excuse they >> can to find something to blame on Microsoft. I'm not saying MS is >> not without blame on many things, but be reasonable! > > No defense of the paranoid claims of the OP, but... > > It is a bit lame that "local file time" changes for all existing files It's the same issue when you change time zones. The displayed time should > when DST changes. The underlying time is kept in UTC and only rendered > for display in the local TZ. These files did not change, nor did their > time stamps -- so why should they appear to have? You could certainly > make a case that it's a design flaw. > change as it is relative to the time zone you are currently in. The actual file time stamps don't include what timezone it originated from. . 
Other interesting topics
Wrap a Long String
Determining Available Paper Sizes on Printer Number Puzzle vb6 closes with erro after I installed msdn oct 2001 Subclassing a la Caton Using VBPRNDLG.DLLl Instead of Print Common Dialog Boxes Error #429 and compactdatabase in VB6 VSM Wants Your Feedback Control Container Property - Why Use It? Does anybody know how to translate this C# code to VB6? |
|||||||||||||||||||||||
