daveb
5th February 2009 10:27 UTC
Preserving local dates when unpacking files
In 2003 we patched v2.0b3 of NSIS to fix a problem we were having when unpacking files in different timezones.
Our software uses filetimes to determine if imported data is up to date, storing the filetime as data whenever a file contains information read and cached from another file.
So it is particularly important that we maintain consistency in a set of files packaged up in one timezone then unpacked in another. We do not want the system time to be converted due to timezone changes.
We made a relatively simple change, which I carefully documented and we have been using this old version successfully for the last 5 years.
This behaviour may not be what everyone wants, but if put into NSIS as an option, it would be a potentially useful thing for others.
So I was looking at the latest version 2.43 and thought it might be a good idea to make the change in the new version, and contribute this to the project for the benefit of others. It has been working flawlessly for us for many years.
Now trying to make the change to the new version, things are done slightly differently, and I was hoping some expert with current knowledge might be able to help with this, and perhaps put it into the project properly. I am not familiar enough with the SourceForge protocol to take this on properly and try to edit the project source myself. So I have made a start by trying to put the changes in as best I can, and zipped up the files before and after for comparison, and also included the original notes and differences.
I have not attempted to make it optional behaviour, and one of the four changes is not done at all, but this is just the NSIS_VERSION change. This would happen anyhow if merged into the current SourceForge development properly.
kichik
5th February 2009 14:31 UTC
I'm not sure I understand the purpose of this code change. You get the file time in UTC, convert it to the current timezone and then convert it back to UTC on the client's side, assuming you two have the same timezone.
Or were you using FAT back then? FAT returns times in local timezone, unlike NTFS which returns them in UTC. I do see now on MSDN that there's a method to always get UTC time. Open a bug report or submit a patch for it and I'll include it for the next version.
daveb
5th February 2009 23:22 UTC
The problem we have is that the person packing the files is in a different timezone to the person unpacking. We were using both FAT and NTFS, but these days mostly NTFS.
In more detail... here's an example of the problem:
Distribute files A,B,...
Because A contains some data imported from B, data in A also contains the timestamp of B internally.
eg A contains data for B and timestamp B at say "1Feb09,1300"
Pack it all up and distribute.
Now end user unpacks files and tries to use them, but NSIS when unpacking notes timezone change and creates A and B files with adjusted times. So perhaps timestamp of B is now "1Feb09,1800". This now fails to match recorded timestamp in A and application decides incorrectly that imported data needs updating.
We used to pack and unpack files using WinZip. It saves and restores local time, so we devised a timezone invariant C++ class which serialized so that restored data for these timestamps was the same value regardless of timezone. Everything then worked fine as files got shipped across timezones in zips. But for real installs as opposed to little zip updates, we began to use NSIS, and that's when we struck this problem. As I said, we fixed it in the little customization of 2.0b3 that I attached above.
Could be that WinZip is not doing "the right thing", but it is hard to argue the rights and wrongs here. Should the filetimes be adjusted or not? Since WinZip is so all pervasive, it would seem to me a good idea to make this behaviour optional, but if compulsory, I would rather stay in line with WinZip behaviour where if the file says time=1500 when you pack it up, it will still say 1500 when you unpack it, regardless of timezone.
Hope this clarifies the problem anyhow... thanks.
daveb
9th February 2009 12:54 UTC
Submitted as bug report as suggested above, see here:
https://sourceforge.net/tracker/inde...49&atid=373085
(SourceForge id = 2581469)