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