Page MenuHomePhabricator

Possible zim timestamp inconsistency
Closed, InvalidPublic1 Estimated Story Points

Description

Reported by @Kaartic:

Date shown on toast is incorrect (960×540 px, 132 KB)

This looks an awful lot like the timestamp for this file is reported in unexpected units.

Event Timeline

@Kaartic Thanks for reporting! Sorry I missed you, I have not been keeping close tabs on IRC the past few days. What ZIM file is being used here?

This is working as expected: We're currently hard-coding all the parameters of each compilation, including the timestamp, which is basically a random number. We can either update the hard-coded numbers to look like a more plausible timestamp, or wait until we're pulling the data from the service endpoint.

Aha, I thought we'd introduced logic to override the metadata from the compilation client with the actual file metadata upon download, but that doesn't seem to be the case.

The rationale is that ideally we want the time at which the compilation was generated, not the time at which it was modified or downloaded. And currently the only way to get that time is with explicitly coded metadata. Once we start creating our own Zim files, we can include additional metadata in the file itself that contains the date at which it was generated. (Or indeed encode a timestamp for each of the articles contained in the compilation)

@Kaartic Thanks for reporting! Sorry I missed you, I have not been keeping close tabs on IRC the past few days.

No issues :)

What ZIM file is being used here?

Just for the note, it's the Wikipedia Uganda test compilation

@RHo here's the earlier exchange I was referring to about creation vs. DL dates; see discussion above.

Thanks @Mholloway - Dmitry's comment matches my expectation on ticket T166652 (my emboldening):

The rationale is that ideally we want the time at which the compilation was generated, not the time at which it was modified or downloaded. And currently the only way to get that time is with explicitly coded metadata. Once we start creating our own Zim files, we can include additional metadata in the file itself that contains the date at which it was generated. (Or indeed encode a timestamp for each of the articles contained in the compilation)

Oh, OK. I interpreted your first bullet point as a statement of what was wrong rather than what was expected. "Shows" vs. "should show."

My mind's been in the ZIM backend for much of the past week so I wasn't recalling what was currently happening offhand.