Re: kernel 2027

Bart Oldeman <[email protected]> Sun, 10 Nov 2002 00:49:19 -0500 (EST)
Newsgroups gmane.os.freedos.devel
Message-ID <[email protected]>
On Sun, 10 Nov 2002, Arkady V.Belousov wrote:

> 9-îÏÑ-2002 20:59 [email protected] (Bart Oldeman) wrote to
> [email protected]:
>
> >>      And again time shifting. :( In compare 2027 archive content with 2026b,
> >> I see that for equal files time again shifted back by 5 hours. When this
> >> ends?!
> BO> This ends when I stop moving :) I timeshifted exactly 5 hours between the
> BO> UK and here.
> BO> The problem is that your unzipping utility does not honour timezones.
> BO> Set TZ to something that is correct and use "unzip", not "pkunzip", and
> BO> you'll be OK.
>
>      ? Why you think that in this guilty PKUNZIP? AFAIR, .ZIP format not
> contains TZ info, which will[n't] be applied at unzipping time.

It does, IF you zip using INFO-ZIP and unzip using INFO-ZIP -- the zip has
this info in extra fields that PKUNZIP doesn't know about. This is done
precisely because of the problem you see: portability between timezones
and OSes. PKUNZIP simply doesn't care because it thinks that local times
don't change when you move.

Now my FD-kernel copy is on a Linux ext3 filesystem and contains local
times in EST now. When I moved to the US all these times were shifted --
because internally there are stored using UTC and externally displayed
using the local time.

> This is your (as archive creator) task to place files into archive with
> unchanged attributes.

For me, whether I do unzip -l ke2026bsrc.zip or unzip -l ke2027src.zip I
get the same timestamps. That you don't is your problem, not mine (except
for the NLS stuff though, that I cannot explain).

Bart