date modified hour and zip files in DST timezone

[anmac1789]

Hello, I have a question regarding files on my win 10. Currently (as of Oct 18, 2023) I live in the EDT timezone (UTC-4) in Northern US & Canada. I have a zip file with summer and winter dated pictures and when extracted the date modified is ahead of the date taken by 1 hour. When I toggle on/off 'adjust for daylight saving time automatically' then the date modified hour goes back and forth by 1 hour. How can I keep it consistent all throughout the year?

1. What if I extracted a file with summer/spring dates during the autumn/winter months, when my timezone ends DST and we switch from EDT to EST. What happens to the date modified hour?

2. What if I extracted a file with autumn/winter dates during the spring/summer months, when my timezone starts DST and we switch from EST to EDT. What happens to the date modified hour?

[ghisler(Author)]

ZIP files store file times as local time, while the NTFS file system stores them as UTC (universal time). So when switching from/to daylight saving time, either the first or the second will change by one hour.

Total Commander has an option in Configuration - Options - Operation to ignore a time difference of exactly one hour.

[anmac1789]

ZIP files store file times as local time, while the NTFS file system stores them as UTC (universal time). So when switching from/to daylight saving time, either the first or the second will change by one hour.

Total Commander has an option in Configuration - Options - Operation to ignore a time difference of exactly one hour.

So for files having summer dates for example, extracted during winter and waiting until DST starts next year, will have the date modified hour forwarded by one hour ?

basically the question becomes: What happens to files having EDT timezone (UTC-4) date modified extracted from .zip archives in EST (UTC-5) timezone ? and vice versa?

What does Operation to ignore a time difference of exactly one hour exactly do ?

[sqa_wizard]

Well, as said before:

ZIP stores the time as local time only (no timezone).
If you take a photo of sunrise at 6.00 UTC+6 in the morning, pack it as zip and you unpack it at a city at timezone UTC-6 you will still see 6.00 in the morning.
You see:
1. The sunrise photo is taken in the morning of the origin city.
2. You have to calculate your own, what time it was at your own city.

7-ZIP for instance stores the time as UTC (like NTFS file systems do).
If you take a photo of sunrise at 6.00 UTC+6 in the morning, pack it as 7z and you unpack it at a city at timezone UTC-6 you will now see 6.00 in the evening.
You see:
1. The sunrise photo is taken in the evening of your city.
2. You have to calculate your own, what time it was at the origin city.

Different methods have different advantages and draw-backs.

[Hacker]

anmac1789,
FYI, you can also experiment with wincmd.ini - [Configuration]

NewTimeZoneMethod=
1: Windows 7-style timezone method (default on Windows 7)
0: Old method (default on older Windows)

HTH
Roman

[petermad]

You can control it a litte by using NewTimeZoneMethod=0 in the [Configuration] section of wincmd.ini:

NewTimeZoneMethod= 1 Windows 7-style timezone method (default on Windows 7)
0: Old method (default on older Windows)

https://ghisler.ch/board/viewtopic.php?p=399219#p399219
https://ghisler.ch/board/viewtopic.php?p=227606#p227606
https://ghisler.ch/board/viewtopic.php?p=325315#p325315

[anmac1789]

Well, as said before:

ZIP stores the time as local time only (no timezone).
If you take a photo of sunrise at 6.00 UTC+6 in the morning, pack it as zip and you unpack it at a city at timezone UTC-6 you will still see 6.00 in the morning.
You see:
1. The sunrise photo is taken in the morning of the origin city.
2. You have to calculate your own, what time it was at your own city.

7-ZIP for instance stores the time as UTC (like NTFS file systems do).
If you take a photo of sunrise at 6.00 UTC+6 in the morning, pack it as 7z and you unpack it at a city at timezone UTC-6 you will now see 6.00 in the evening.
You see:
1. The sunrise photo is taken in the evening of your city.
2. You have to calculate your own, what time it was at the origin city.

Different methods have different advantages and draw-backs.

ZIP stores the time as local time only (no timezone).

Well that's not completely true because, if i toggle 'adjust for daylight saving time automatically' in windows setting, the time flips back and forth an hour inside the zip file too (im using winrar to open .zip archive)

but my question is only regarding EST/EDT in UTC-5/UTC-4 timezones in Eastern Canada. Right now, I've experimented that toggling on/off 'adjust for daylight saving time automatically' in windows settings, doesn't change date modified hour of pictures taken during the winter for some reason. But for pictures taken during the spring/summer, always change. Why is this ? Is this behavour going to to happen to winter pictures in winter months ?

[anmac1789]

What's even more stranger is that when adding files to a zip made with total commander, it's off by 1 second for some reason. WinRAR and 7zip don't have this problem. Is there something behind the scenes with total commander that it's not preserving the full timestamp including seconds ?

When using the zip packer, the files inside the .zip are not affected by DST changes. However, the seconds are -1. If somehow, this could be fixed, then the zip archive is complete with total commander.

[petermad]

2anmac1789

when adding files to a zip made with total commander, it's off by 1 second for some reason.

Zip uses the same time stamp resolution as FAT partitions on a harddisk - FAT can only store even seconds, so if you copy a file with uneven seconds from a NTFS drive to a FAT drive, then 1 is added to the seconds.


https://devblogs.microsoft.com/oldnewthing/20151030-00/?p=91881
https://en.wikipedia.org/wiki/ZIP_%28file_format%29

The FAT filesystem of DOS has a timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.

[anmac1789]

2anmac1789

when adding files to a zip made with total commander, it's off by 1 second for some reason.

Zip uses the same time stamp resolution as FAT partitions on a harddisk - FAT can only store even seconds, so if you copy a file with uneven seconds from a NTFS drive to a FAT drive, then 1 is added to the seconds.


https://devblogs.microsoft.com/oldnewthing/20151030-00/?p=91881
https://en.wikipedia.org/wiki/ZIP_%28file_format%29

The FAT filesystem of DOS has a timestamp resolution of only two seconds; ZIP file records mimic this. As a result, the built-in timestamp resolution of files in a ZIP archive is only two seconds, though extra fields can be used to store more precise timestamps. The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.

So are you going to increase time resolution to include odd and even seconds ? but without timezone information ? How to fix this ? Also, the source file is on a windows network drive from using a webdav server app on android

[Dalai]

How to fix this ?

Use an appropriate archive format like 7Z or RAR which can store precise timestamps and save them in UTC.

Regards
Dalai

[petermad]

So are you going to increase time resolution

I am not going to to do anything - I am just pointing out that in ZIP files, seconds are only stored as even numbers by default - it has nothing to do with TC, it is a limitation for the ZIP format.

[anmac1789]

But i dont want the times to change under DST when i extract from zip but i do want slightly higher second resolution is this possible ?

[anmac1789]

How to fix this ?

Use an appropriate archive format like 7Z or RAR which can store precise timestamps and save them in UTC.

Regards
Dalai

I prefer the FAT like behaviour of timestamps in the sense that it doesnt change when DST on or off but i want higher time resolution without the timezone information or UTC timestamps

[Horst.Epp]

I prefer the FAT like behaviour of timestamps in the sense that it doesnt change when DST on or off but i want higher time resolution without the timezone information or UTC timestamps

Accept the facts.
FAT has no higher time resolution, TC or any other file manager can't change that.