On Mon, 11 Oct 2004 11:47:57 +1300 Rik Tindall <[EMAIL PROTECTED]> wrote:
> FWIW, this observation may be related to the problem under discussion.. > > Volker Kuhlmann wrote: > > >In your case, suddenly having time in the middle of the night is > >indicative for a time zone mismatch. Keep in mind that Billyware(TM) > >expects to go on local time whereever your are, resulting in a big > >screwup when you go international. A lot of software is then unable to > >handle this properly. You may need to configure samba to use the correct > >timezone. I have also observed that Billyware with about version 2000 > >shifted from local time to UTC when file servers are concerned, causing > >yet more chaos. On the positive, this might eentually fix the problem > >where the times on all the files in the other half of the year are out > >by one hour (as Billy isn't able to take of the daylight saving > >difference properly). > > > >In your case it looks like you're having a time zone problem as well as > >a problem with timestamps not being copied. A time zone problem shows up > >as times being wrong by about 12 hours. Timestamps not being copied > >shows up as all files having the same time stamp (that of when they were > >copied). > > > A recurring issue I have with dual boot systems (Win + SuSE, Ubuntu, ..) > is settling the time/date across all platforms. There is something > significantly different about the way this record is stored in Win vs > Linux. > > I always go with the defaults/CLUG recommendation at installtime (local > time + NZ/Ackd), but adjusting the time/date setting to be correct in > Linux tends to throw the system clock back 12 hours (hence Roger's 3am?) > under Windows. And vice versa, only then it's forward in Linux. > > Is it a function of displayed time/date in Linux being different to the > actual system clock reading, which gets recorded / rewritten at power down? at the risk of repeating myself, all times are stored in unix as UTC - filetimes and the system internal clock (run by the kernel). the reason you see something different when you type date or ls -l is your localtime, set usually by /etc/localtime. that file is often a link to a file in /usr/share/zoneinfo - in our case it should be /usr/share/zoneinfo/Pacific/Auckland [1] the bios or hardware clock is only used at startup to get a seed for the kernel's clock. the hardware clock can be stored as localtime or UTC, linux does not care, as long as it knows at startup what it is getting, and what to store at shutdown. you could tell it to subtract or add a million years to the hardware clock, as long as it made the reverse calculation at startup as at shutdown. windows _does_ care though, it expects the hardware clock to be stored as local time. this i am sure is true of all 16 bit windows (95.98/ME). I am not so sure about nt/2k/xp - they _may_ have a setting to tell windows to expect the hardware clock to be UTC. - check that out Rik, that may be the problem. Setting the hardware clock as localtime has always worked for me on dualboot 2K/linux, i have never set up a dual booted XP system. However you should be aware that if there is such an option in windows XP it may be affecting you. i have seen comments on a list recently that indicated that some particular motherboard did not seem to be reporting the hardware clock properly to unix on startup, but we never got to the bottom of it. [1] some systems copy the zoneinfo file to /etc/localtime instead of making a link - i prefer the link, its easy to see what the setting is by typing ls -l /etc/localtime and seeing where the link points to. > > hth > > Rik > -- Nick Rout <[EMAIL PROTECTED]>
