Macbinary creation dates are set to mod date

[GoogleCodeExporter]

Simple problem: When decoding macbinary files the creation date gets set to the 
modification date 
instead.

Original issue reported on code.google.com by andrew...@gmail.com on 11 Apr 2007 at 9:37

[GoogleCodeExporter]

libxad only handles a single date for each file. Changing this would take a 
large
amount of rewriting and is not worth it for the minimal benefit.

Original comment by paracel...@gmail.com on 20 Apr 2007 at 6:05

• Changed state: Invalid

[GoogleCodeExporter]

Seems modification dates are implemented now. Thanks :)
(although for MacBinary files, both dates always come out exactly 1 day and 2 
hours 
ahead of what they should be)

Original comment by andrew...@gmail.com on 25 Oct 2009 at 4:20

[GoogleCodeExporter]

The 2 hours I'd imagine is because the date is stored as the local and not the 
GMT time, 
which I'm not sure if I want to try and fix - it'd still be wrong in another 
timezone.

The one day is a bit more strange, though. Perhaps my date calculation is off? 
Do you 
have any StuffIt files with known dates you can check? They use the same 
conversion 
code.

Original comment by paracel...@gmail.com on 15 Nov 2009 at 7:34

[GoogleCodeExporter]

Aha, timezones. I tested again using OS X's macbinary encoder and when 
extracted with 
The Unarchiver, the difference was only 13 hours. So yeah, it can all be 
attributed to 
timezones and the exact behaviour of the program that created the file. I guess 
with the 
file I was originally testing on it somehow got doubled up.

I think the way OS X's one works it it simply adds the current timezone offset 
when 
encoding and subtracts it when decoding.

Original comment by andrew...@gmail.com on 16 Nov 2009 at 1:53

[GoogleCodeExporter]

I didn't even know there was a macbinary encoder in OS X! That makes testing a 
bit 
easier, I guess...

Anyway, I tried it, and I get a time offset of exactly one day. That part I can 
understand 
easily, I probably just got the offset wrong by one day. But now I'm mystified 
by why 
you got a 13-hour offset instead. (I'm at GMT+2, I haven't tested any other 
timezones.)

Original comment by paracel...@gmail.com on 16 Nov 2009 at 8:19

[GoogleCodeExporter]

Oh sorry, forgot to mention I'm at GMT+13. I thought that explained the 
difference for 
me but perhaps not. Adjusting my time zone I also see 24 hours at GMT+2 and 
then 26 
hours at GMT+0. Strange...

Original comment by andrew...@gmail.com on 16 Nov 2009 at 10:32

[GoogleCodeExporter]

I guess this requires some more research. I wish I had some files produced by 
some 
other software and with known exact times, in case the OS X one is doing 
something 
funny.

Original comment by paracel...@gmail.com on 16 Nov 2009 at 10:49

[GoogleCodeExporter]

Well, I changed the offset again and made it use the local timezone instead of 
GMT,
which seems to produce correct results for the single macbinary test case I 
have with
a known timestamp. Hopefully it's not too far off for other things.

It seems StuffIt has different (and wrong) ideas about what the timestamp 
should be,
too, so I guess being wrong here is pretty common.

Original comment by paracel...@gmail.com on 17 Nov 2009 at 1:58

[GoogleCodeExporter]

Checked out the latest build - works here too, thanks!

Original comment by andrew...@gmail.com on 17 Nov 2009 at 10:07

[GoogleCodeExporter]

Excellent.

Original comment by paracel...@gmail.com on 17 Nov 2009 at 10:24