FileHeader times change depending on the current timezone about junrar HOT 9 CLOSED

It's working now 😃

from junrar.

DOS times are dependent on timezones.

A DOS time is a packed 16-bit value containing Year (since 1980), Month (1 to 12), Day (1 to 31), hour (0 to 23), minute (0 to 59) and seconds (0 to 58, only even seconds gets stored).

All times in a RAR file are stored as DOS dates. They're therefore timezone dependant, when you're converting them to standard, fixed reference time (like Java's milliseconds since epoch).

See https://codedread.github.io/bitjs/docs/unrar.html#ext-time-structure for more details.

from junrar.

Additional explanation: RAR has a flag to compensate for the missing odd seconds and it also stores sub-seconds time, but it's still a DOS date, although expanded.

from junrar.

The test class with multiple timezones is intentional for testing the constancy of the decoded time under different zones 😉

from junrar.

so that means we can't convert the times to Instant and expect them to match if the timezone doesn't, correct?

So it might not be a bug, but in that case do you have any idea on what's the best way to compare those dates, when they are being compared across timezones ?

I've got a regression test corpus that store JSON files of all the files in the corpus, and i can check the archive process again against the stored value, however when trying to set it up in Github Actions it fails because the dates are offset by 8.

from junrar.

Or maybe what i need to do is generate the reference data in UTC, and always compare in UTC?

from junrar.

No, we can't expect them to match.

If we know the original timezone, though, we can compare it to the expected instant at that timezone, maybe using a LocalDateTime or something.

But just an FYI, that was already the case before #76. mTime was always stored as a DOS date. #76 only added the odd second and sub-seconds parts of it.

It's working as per the specification. We need to change how we compare it in the failing test.

I'd need to take a look at the specific test and see how it's doing it.

from junrar.

I will try to regenerate the data in UTC, and compare in UTC. Easy to do with @DefaultTimeZone("UTC").

As of now the data was generated in UTC+8, and the regression test works fine on the same machine, but fails on Github which i suspect is in UTC, which matches with the 8h different i see in the failing assertions.

Thanks for refreshing my memory on the DOS time 😃

from junrar.

Yes, that would work :)

If you want to be thorough, you can generate two JSONs, each on a different time zone, and code two tests with two different time zones :) I think I've done something similar in a test already

from junrar.