On 11/22/06, Oliver Betz <email@example.com> wrote:
> Erik Huelsmann wrote:
> > > > Subversion itself does not have any DST/UTC calculations. For those
> > > > calculations, it depends on the C runtime library available on your
> > > > platform. In case of Linux, that would normally mean glibc. In case of
> > >
> > > which is broken (real stupid thing happened...), see
> > >
> > > http://search.cpan.org/~shay/Win32-UTCFileTime-1.45/lib/Win32/UTCFileTime.pm#BACKGROUND_REFERENCE
> > > or http://www.codeproject.com/datetime/dstbugs.asp
> sorry, these links didn't describe the real problem very clearly.
> And Jonathan Gilligan followed partly the same "non UTC centric"
> thinking causing all this trouble. IMO ist's the correct behaviour
> that DIR (or ls or whatever) shows a different time between DST and
> non-DST periods.
> > After reading the latter link, which says that Windows is broken for
> > timestamps on files, I understand the problem is confined to FAT
> > drives.
> The problem with FAT files is that they don't know (can't know) the
> timezone the refer to, so you never can know their UTC time. One
> should avoid FAT where file creation or modification times are
> important. I don't want even to think about the best handling of FAT
> file times.
> > But Subversion as things stand, is already broken on FAT
> > drives, but works fine on NTFS. This all means that Subversion won't
> > suffer any of the problems described. Am I right?
> Maybe no: the problem is that stat() is broken in Microsoft C when
> you want to get the UTC mtime of a file. IIRC, you get the wrong time
> if the file is in DST and the system time is not or vice versa.
> I don't know whether subversion for Win32 uses stat() and whether
> it's compiled with the broken MS C.
> Win32 API calls should work.
Ok. Well, Subversion doesn't use stat() calls: it uses function calls
to APR functions which get the desired information. APR uses (AFAICT)
Win32 API functions to retrieve the requested info. So, given your
above statement, it should work, but the question that remains: are
there API functions which are broken in the same respect, or do all
APIs work correctly?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 22 16:33:06 2006