Re: Time zone changes and "tar --list --verbose"

[Jakob Bohm]

On 2020-10-28 19:35, Paul Eggert wrote:
> On 10/28/20 5:22 AM, Sergey Poznyakoff wrote:
> > > Is there a way to prevent this?
> > No, there is not (apart from setting the TZ variable before running 
> > tar).
>
> To spell this out a bit more verbosely:
>
> On a GNU or POSIXish system, the TZ variable says how to decode the 
> timestamps from UTC. If you use TZ='America/Los_Angeles', for example, 
> you'll get the same output from 'tar -tv' regardless of whether you 
> run 'tar' in summer or in winter.
>
> On a Microsoft Windows system, it's easier to get this wrong, as 
> MS-Windows historically used local time rather than UTC internally, 
> and there are hacks to convert between local time and UTC that often 
> go awry. Possibly this is the problem the user ran into. There may 
> well be a workaround involving setting TZ, but the user may need 
> someone with MS-Windows expertise to figure out what actually happened.
Information for Windows (Win32):
    On Win32, there are two public APIs to do the UTC-to-local conversion:

1. FileTimeToLocalFileTime() works directly on 64 bit numeric FILETIME
  values (100ns units since 1600-01-01 00:00:00).  This always uses the
  current local-to-utc offset value regardless what time of year the
  time value represents.  This API is "suggested" for actual file time
  stamps, and is used internally when reading local time from FAT based
  file systems.  Thus to round trip file modification time on FAT file
  systems (such as SD cards), this call will make the same mistakes as
  the file system driver does.

2. SystemTimeToTzSpecificLocalTime() works with calendar-style SYSTEMTIME
  structures (similar to POSIX struct tm) and uses the time offset for
  the actual time represented.  This API uses the daylight savings time
  tables for the current (or specified) timezone.

Neither API looks at the POSIX TZ environment variable, using instead
the system-wide internal state as loaded from the registry.

Now when a ported POSIX application such as GNU tar invokes the stat()
and localtime() system calls, the different portability libraries may
use different strategies to convert the file times returned by Win32
APIs to and from POSIX time_t values.  Some older libraries would
foolishly do extraneous roundtrips through local time, sometimes using
the wrong time zone offsets, while properly implemented libraries will
use the fact that FILETIME values have direct numeric conversion to
time_t by simply dividing by 10 million and subtracting the number of
seconds between 1600 and 1970.  The localtime() implementations may
similarly be using any wrong or correct timezone conversion.

So in the end, it is a matter of checking the implementation code in
the POSIX-compatibility layer used.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded