Apologies if this is a repeat (if so please remove this). Previous post several hours ago still has not shown up in the list.
This is a follow up to an issue that came up in a separate topic (Name and date of exe at runtime?). Creating a new topic here as it was separate to the issue originally raised.
It appears that UNPACKTIMEQQ does not correctly handle Daylight Saving time; eg. as noted previously, it appears to double account for Daylight Saving, at least in some situations; eg. program compiled on 5 April 2013 @ 11:52 NZ DST. On running the program a few seconds (or few hours) later, the exe file creation time reported ex UNPACKTIMEQQ is 1 hour too large (12:52). "Date created" time reported in File Explorer was correct; ie. shown as "5/04/2013 11:52am". From what I can determine, the time info extracted by GETFILEINFOQQ appears to be correct; ie. seconds since 1970_01_01 00:00:00 (UT), so the problem appears to be in UNPACKTIMEQQ.
Daylight saving ended in NZ early am yesterday. Running the same exe today (8 April) yields the creation date as "5/04/2013 11:52" which is correct for NZ DST that applied on the creation date. However, as I understand it, (at least some?) Windows "local time" functions use the current settings for the time zone at query time; ie. would report NZ Standard Time for creation date even though the file was created in DST?.
Hence it is not clear if the time reported now by UNPACKTIMEQQ (11:52) is correct? ie. is the output intended to be for the current settings of the time zone at run time (ie. NZ Standard Time at creation was 10:52) or in terms of local time applying at creation (NZ DST 11:52)?
Regardless of whether the time being reported now is 'correct', clearly it was not when compiled and run in NZ DST.
Any likelihood of this issue being investigated / fixed?
As others pointed out this does appear to be a DST issue. Compiling and running today (in NZ Standard Time) generates the correct creation date and time. Have to wait to test the reverse (create in standard time, run in daylight savings time).
I later realised that as this program is used in 3-4 countries (in different time zones), reporting local time will probably lead to confusion. Decided therefore to 'roll my own' unpack routine to obtain UT. Have attached a copy if anyone is interested. Not fully debugged (especially the leap year stuff) so no guarantee that there are not errors but it seems to work correctly at current date. Also likely that there are more efficient ways of doing some of the calculations but as this is only called once in a large program, fine tuning efficiency is not warranted (for my use!).
Thanks re "packtimeqq 'feature'"
In the case of UNPACKTIMEQQ though, there is a (probably related) but different error in that it is making a 2 hr 'correction' for day light saving, resulting in a time 1 hr in the future.
The problem with both with pack and unpack is the daylightsaving gives some unforeen and unpredictable results. In my case times saved in a a database could be comopared with times from other (unknown) time zones. The simple answer if it is important in the aplliaction is not to relay on the pack and unpack functions. In my case I wrote my own pack and unpack functions so I was always working in UTC.
For me the intel 'solution' should be just add some notes to the help file to avoid the recurring confusion of users.