correct epoch_1_jan_1904

[Nadahar]

@drewnoakes This might be nothing, but isn't it a bit strange how you could have come up with "the wrong constant"? I'm thinking that maybe the "Java epoch" isn't always the same for all platforms, and that this might explain how this came to be.

The constant was introduced when you refactored #410 in https://github.com/drewnoakes/metadata-extractor/commit/be7c4c8fc809ecd6de885f05dcf710a888938d9d as far as I can understand. The way I originally made it, the difference was "calculated" by each individual system. I'm just wondering if that might ultimately be the correct solution. This was the original code:

        // Calculate the difference between the Java Epoch and the MP4 Epoch
        Calendar calendar = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
        calendar.set(1904, 0, 1, 0, 0, 0); // January 1, 1904  -  Macintosh/MP4/QuickTime Time Epoch
        MP4_EPOCH_OFFSET = calendar.getTime().getTime();

The initialization was done in a static initializer, so I don't thing the "cost" of doing it this way matters much.

[choim4389]

@Nadahar calendar.set(1904, 0, 1, 0, 0, 0) doesn't set milliseconds. So, previous milliseconds value would be remained. Therefore every set() could returns the different ms value.

To avoid that call calendar.clear() before set(). it clears remained ms value and after that calendar.getTime().getTime() always returns -2082844800000.

[Nadahar]

@choim4389 Ah, that explains everything then. I must say that it's a strange behavior on the part of Calendar that I wasn't aware of, but it indicates that using a (correct) constant is the best solution.

@drewnoakes I'd sayt just merge this :wink:

[drewnoakes]

Thanks all for the investigation here. At least we understand why we had a weird constant there.

[drewnoakes]

Released in 2.15.0.