Date discrepancy in uploads (probably due to timezones)

[misaochan]

Summary:

https://commons.wikimedia.org/wiki/File:Fruit_tea_store.jpg

Summary section says "Date | 2 January 2020 (according to Exif data)", whereas the EXIF section at the bottom says "Date and time of data generation | 15:01, 1 January 2020".

Device and Android version:

Samsung Galaxy S8, Android 10

Commons app version:

master, d7a42b2f89a35e1d80bf458538d95b93a66840c1

[sivaraam]

Curiously enough the editing the summary of that image reveals the following:

...

|date={{According to Exif data|2020-01-02}}

...

The Template:According to Exif data - Wikimedia Commons page gives some information about how the template works.

I'm wondering if the date parameter is something we set or if it gets added automatically?

[318anushka]

Do you think this has something to do with timezone? I was just checking onto it and created date of contribution shows this: 2020-04-10 05:18:01.736 22623-22623/fr.free.nrw.commons D/CREATEDATE MODEL: Thu Apr 09 01:47:25 GMT+05:30 2020 which is exactly 5:30 ahead of IST(my current time zone)(Although ist is ahead of gmt) Exif details of photo shows this 20:17, 8 April 2020.

[sivaraam]

Do you think this has something to do with timezone?

Yeah, that's a possibility.

For the image mentioned in the description too the timestamp in EXIF is 15:01, 1 January 2020. If you add 10 hours for GMT+10, the date does fall in 2 January 2020. Interesting 🤔

[sivaraam]

I'm wondering if we should treat the timestamp in the EXIF as GMT or as a timestamp in the corresponding timezone in which the image was taken? 🤔

[macgills]

given the method we are using

/**
     * Returns number of milliseconds since Jan. 1, 1970, midnight local time.
     * Returns -1 if the date time information if not available.
     * @hide
     */
    @RestrictTo(RestrictTo.Scope.LIBRARY)
    public long getDateTime() {

and the other method available

    /**
     * Returns number of milliseconds since Jan. 1, 1970, midnight UTC.
     * Returns -1 if the date time information if not available.
     * @hide
     */
    @RestrictTo(RestrictTo.Scope.LIBRARY)
    public long getGpsDateTime() {

I would say we are treating non UTC as UTC.

If we are getting more serious about Date then we absolutely should be using 310ABP to handle these situations

[318anushka]

Well, looks like it's currently treating it as GMT and then converting it

[misaochan]

Yes, I think it's likely a timezone issue - my timezone is +10.

I just went through my old uploads and this one from an older version has the same issue: https://commons.wikimedia.org/wiki/File:View_from_Mt_Coot-tha.jpg . So I think we can safely say that this has been around for a while, and it is not urgent to fix it before the release. I have removed it from the 2.13 list.

Is there a reason we would use the external 310ABP library over https://developer.android.com/reference/java/util/TimeZone.html ?

[macgills]

Yes, the java team made the new java.time API because Date, etc were hideous and Joda had some issues design wise. More can be read on the joda page.

In android for a while if you were doing anything serious wrt to time you used joda, because of the long history of java features not making it to android we didn't (and still don't) have access to the standard time library, (kotlin currently has an experimental Duration API that I am hoping will be expanded upon in 1.4+) hence this android flavoured version of the backport of the "new" time libraries, java 8 released with them in 2014.

[subbass1]

I also encountered a problem with the date, e.g. see here: https://commons.wikimedia.org/wiki/File:Reinhausen,_St._Christophorus,Orgel(5).jpg To me it seems that on uploading the "Speicherzeitpunkt" (saving date) is altered, I'm not sure if this is correct, on other uploads both time lines are the same, iirc (there seems to be additionally a problem with UTC). But even if: the app uses the wrong "line", correct would be "Erfassungszeitpunkt" (capture date).

[misaochan]

Is anyone interested in taking this up or diagnosing it further? We have another report at https://commons.wikimedia.org/wiki/Commons:Village_pump#Bug_report_for_wrong_cats_on_upload

[sivaraam]

@misaochan Just to make it more clear, is this issue only about diagnosing the issue and fixing it or does it also involve using the 310ABP library that Macgills mentions in one of the earlier comments?

[misaochan]

Diagnosing and fixing it. Switching to 310ABP is a potential method for fixing the problem (and would be a nice upgrade), but it's not strictly necessary.

[whym]

I changed the title of this issue to differentiate it from #1971. (The latter seems more wide-ranging.)