zip: Fix incorrect time/date, add extended timestamp and refactor #793
Conversation
wader
force-pushed
the
zip-correct-date-time-fields
branch
2 times, most recently
from
1f9d4c3
to
f79afdf
Compare
|
Example: |
wader
force-pushed
the
zip-correct-date-time-fields
branch
from
f79afdf
to
c571ed7
Compare
|
Good catch. As i understand it the last modification that uses msdos format (not the extended timestamp) has no timezone? is local? so i changed to remove the "Z". I also changed so that second field is now shown *2, is less confusing? |
|
Removing Z sounds good to me. This page also says MSDOS times don't have a timezone: http://fileformats.archiveteam.org/wiki/MS-DOS_date/time About raw seconds or *2, what does fq do in other such cases? For what it's worth, year is also year+1980. Currently the output is: I feel I'm nitpicking really minor details at this point, but |
It's mostly up to a format decoder how to "model" things. Each field (the thing in the tree and has a name) is tied to a "decode value" that consist of an optional backing bit buffer and range (otherwise seen as "synthetic"), a actual value, an optional symbolic value and a description. The symbolic value is the default value if set, otherwise actual is used in expression etc. One can use So in this case i can see some alternatives: (using year as example) year: synthetic with actual value 2000 Or year: synthetic with actual value 20 and symbolic value 2000 If the msdos timestamp was not little-endian with non-byte-aligned bit-ranges (month and minute is not a continuous bit range i think?) i would probably have model year as actual 20 and symbolic 2000. Maybe should do that even when synthetic then?
No worries! glad there is someone else to discuss with, quite a lot of time writing decoders is actually lots of debating with one self about such things :) Guess here means use locally configured timezone where fq i running? yeah that feels a bit shaky, have a feeling it's good to keep the output not dependent on such things. So is the option to include it all or clearly somehow indicated assumed timezone (UTC?)? rename it to What did you mean by "only the (...)" btw? |
|
Hmm, does that mean you can show " Oh sorry, by "only the (...)" I meant remove the timestamp number and only keep the part that is currently shown between ( and ). I.e. |
Yeap but it would probably be the other way around:
Aha i see, problem is the |
wader
force-pushed
the
zip-correct-date-time-fields
branch
3 times, most recently
from
0403a55
to
a148f76
Compare
|
Added a description to |
MSDOS time/date was read in wrong order and also did not take into account that the bit ranges in the shortis are in little-endian. Remodel modification_time/date to be one struct with fat_time, fat_date LE shorts and then synthetic values for day, hours, minute etc and also a unix field with the timestamp as unix time. Also refactor and clenaup extra fields/extended code a bit. Fixes #792
wader
force-pushed
the
zip-correct-date-time-fields
branch
from
a148f76
to
a83cac6
Compare
|
Looks ok. My main disagreement is that in the grand question of "use UTC (thus, behave differently than what |
|
Thanks for reviewing. I'm trying to convince myself if it's a good or bad idea for the output to depend on local settings or not, feels somehow safer and less surprising to not? What would you pick instead of UTC? |
|
Either UTC, or local, or nothing. UTC is fine. Ship it. |
|
Agree! thanks for talking your time |
MSDOS time/date was read in wrong order and also did not take into account that the bit ranges in the shortis are in little-endian.
Remodel modification_time/date to be one struct with fat_time, fat_date LE shorts and then synthetic values for day, hours, minute etc and also a unix field with the timestamp as unix time.
Also refactor and clenaup extra fields/extended code a bit.
Fixes #792