There are applications where converting timestamps are not desirable. For example, when files are authenticated based on fixed timestamps, converting timestamps can cause authentications to fail. Furthermore, in 7-Zip File Manager's implementation, there are several problems with the time conversion process:
Changing day of the year (without changing time zone) through Control Panel alone can cause the timestamps to be altered, if the system's time zone support Daylight Savings Time. Unless the time zone is changed, timestamps should not be altered for proper handling. This affects adding, listing, extracting, updating operations.
Although 7-zip tries to use UTC time, files stored in archive via 7-Zip File Manager do not preserve the source system's time-related locale settings, so there is no way for user to tell if UTC time is actually used, or 7-Zip File Manager simply guesses. That is, assuming 7z archive is capable of storing multiple versions of same time stamp types for each file (zip archive can).
Assuming an archive can distinguish whether it is using UTC time for each file, there is no facility within 7-Zip File Manager to manually choose only 1 version of timestamps, nor there is a mean for user to see multiple versions of timestamps of the same file.
Even when files stored within an archive is meant to be preserved in UTC format, a time zone database update can alter time zone and Daylight Savings Time settings, which will affect the extracted timestamps for the users' systems. In this case, there is a need to bypass the system's default locale settings to properly preserve the files' original timestamps. Undoing time zone database updates may not be possible for users within networked systems, so the bypasses need to be done at application level.
Therefore, for archive operation purposes, 7-Zip File Manager to inform users when UTC is used, how UTC is used, and when necessary, override time zone conversions.