Fix sorting by dateTaken and dateModified

[paperboyo]

dateTaken acquiring logic much improved (see last comment). We should fix sorting by dateTaken and dateModified.

Hello,

Grid’s is not able to acquire dateTaken correctly. Here is a bunch of examples converted using latest Lightroom: [PROD]search?query=~"dev blog"&uploadedBy=[me]@guardian.co.uk

All dates are (and, consequently, ordering) are wrongly set at:
"dateTaken": "2016-06-10T00:00:00Z",

We already read correct dateTaken which is recorded in multiple places inside fileMetadata, e.g.:

iptc": {
    "Digital Time Created": "15:28:37",
    "Digital Date Created": "20160610",
    "Time Created": "15:28:37",
    "Date Created": "Fri Jun 10 00:00:00 UTC 2016"  
"exifSub": {
"Date/Time Original": "2016:06:10 15:28:37",
    "Date/Time Digitized": "2016:06:10 15:28:37",

Recent updates to metadata-extractor cite

Considerable overhaul of date, time and time zone handling across the library #153 #154 #155 #158

Maybe if we would to update it, we wouldn’t have to think too hard about how should we reconcile the dates ourselves?

FYI, full exiftool dump reveals:

---- ExifTool ----
ExifTool Version Number         : 10.09
---- File ----

File Modification Date/Time     : 2016:06:10 22:55:19+01:00
File Access Date/Time           : 2016:06:10 22:17:27+01:00
File Creation Date/Time         : 2016:06:10 22:17:27+01:00
---- EXIF ----
Modify Date                     : 2016:06:10 22:17:29
Date/Time Original              : 2016:06:10 15:28:37
Create Date                     : 2016:06:10 15:28:37
---- XMP ----
Modify Date                     : 2016:06:10 22:17:29+01:00
Create Date                     : 2016:06:10 15:28:37
Metadata Date                   : 2016:06:10 22:55:19+01:00
Date Created                    : 2016:06:10 15:28:37
History When                    : 2016:06:10 22:17:29+01:00*2016:06:10 22:54:54+01:00*2016:06:10 22:55:19+01:00
---- IPTC ----
Date Created                    : 2016:06:10
Time Created                    : 15:28:37
Digital Creation Date           : 2016:06:10
Digital Creation Time           : 15:28:37
---- Composite ----
Date/Time Created               : 2016:06:10 15:28:37
Digital Creation Date/Time      : 2016:06:10 15:28:37

Regards
Mateusz

[paperboyo]

Also, this all-too-common "dateTaken": "2016-06-14T00:00:00Z" shows up in the UI differently depending on client's time zone. In my semi-holiday location (PL), it becomes:

"Taken on 14 Jun 2016, 02:00"

Hmm...

[paperboyo]

From my very crude tests, it looks like huge majority of all images (~3/4) haven't got time in dateTaken read correctly. Please compare:

[PROD]/search?dateField=taken&takenSince=2016-06-12T23:59:59.999Z&takenUntil=2016-06-13T00:00:01.000Z (16 289 matches)

[PROD]/search?dateField=taken&takenSince=2016-06-13T00:00:01.000Z&takenUntil=2016-06-13T23:59:59.999Z (4 721 matches)

[paperboyo]

Also, even when we read the time of dateTaken correctly, we do not read seconds (which most probably affects thumbnail ordering...). Example: e47473bc39977c75eed3bb1711c52baded013a18 (we read dateTaken: "2016-06-13T15:02:00Z" while Date/Time Original: "2016:06:13 17:02:46" or Date/Time Digitized: "2016:06:13 17:02:46"). Also, the timezone seems wrong (although, I can't get my head around this ever...).

[paperboyo]

See drewnoakes/metadata-extractor#158 and drewnoakes/metadata-extractor#344 for a method of getting composite values from multiple tags including sub-second values and time zone. Meta-isuue: drewnoakes/metadata-extractor#147.

[paperboyo]

Greatly improved by #2180!

Current reconcilliation can be improved still, MWG recommends some sensible fallbacks. Also see.

We should fix sorting by dateTaken. We should decide what to do with partial dates (no subseconds, no seconds, esp. no hours) – read them and fallback on sort to uploadTime?

[paperboyo]

Just adding this in case it will ever be useful (thanks, @davidfurey!): https://www.loc.gov/standards/datetime/