DateTime information is misleading

[carpeliam]

Currently when parsing a date, exif-reader expresses the date in UTC, regardless of any supplemental information available in the exif. This often results in reporting dates incorrectly.

There are a few tags available for knowing timezone offset, including TimeZoneOffset (currently included but not supported by my device) and OffsetTime/OffsetTimeOriginal/OffsetTimeDigitized.

It would be great if the library could, when it's capable of knowing the full date with timezone, return that full date somehow.

It would also be nice to include tags for OffsetTime (0x9010), OffsetTimeOriginal (0x9011), and OffsetTimeDigitized (0x9012). I'd be happy to create a PR for any part of this if that'd be helpful.

[atombrenner]

The tags you are mentioning are represented as part of the Photo set: https://github.com/devongovett/exif-reader/blob/master/index.d.ts#L286-L288.
IMHO combining a UTC timestamp with a timezone to generate local time should be done by the client. The Date object used by Exif Reader has no way to represent a time offset or a timezone. Combining both fields internally would make the meaning ambiguous, as client no longer know if the date is local or utc time (e.g. if no timezone is present in the exif data).

[carpeliam]

I think I partially agree with you. Technically the Date object does represent timezone/offset, and the doc you link to is pretty explicit about things like "2011-10-10T14:48:00.000+09:00" being a valid date. All JS Date objects are timezone-specific, though they're all expressed in UTC:

console.log(new Date("2011-10-10T14:48:00.000+09:00")); // 2011-10-10T05:48:00.000Z

Because Dates can't be created without a timezone, by returning a Date, you are combining both local time and offset internally, you're just specifying a different timezone than what's in the EXIF.

It'd be cool if you could return a Temporal object, but it's not really supported yet. If exif-reader returned a String representation of the date, it would be obvious that it's the client's responsibility to construct a date, maybe using something like blakeembrey/exif-date (which does parse timezone if it's part of the string).

Personally I filed an issue because I think it's a bit misleading currently, and technically incorrect, but I held off on a PR because I'm not really in love with any of the solutions. Maybe return a String value, so it's obviously the client's responsibility? Or document this behavior in the README? Maybe something like "all Date objects are specified in UTC, whether or not the payload includes timezone offset; you'll need to modify the dates if you want them to be in the right timezone"? I've already figured out how to work around it, but I'm not sure if it'll be confusing to the next person.

About the tags: thanks for pointing that out! It's interesting, I'm using a downstream library (titarenko/fast-exif) and it gives me something like the following output:

// see https://github.com/titarenko/fast-exif/blob/master/src/index.ts
import exifReader from "exif-reader";
exifReader(exifBuffer);
exif == {
  '36880': '-04:00',
  '36881': '-04:00',
  '36882': '-04:00',
  '42080': 2,
  ExifVersion: <Buffer 30 32 33 32>,
  DateTimeOriginal: 2024-05-06T10:07:10.000Z,
  DateTimeDigitized: 2024-05-06T10:07:10.000Z,
  SubSecTime: '089',
  SubSecTimeOriginal: '089',
  SubSecTimeDigitized: '089',
  LensMake: 'Apple',
  // ...
}

It only reads in the first 512 bytes of the file, I wonder if that might be it. I'll investigate a bit more to see if calling exif-reader directly results in the same thing.

[carpeliam]

Following up on the tags: I used jpg-stream to read an image, and the tags come back with '36881' etc as in the previous comment - if that's unexpected, I'd be happy to supply a test image.

Incidentally, MikeKovarik/exifr also returns a Date for DateTimeOriginal, but it's always in the same timezone as the client, regardless of where the photo was taken/what the EXIF data says. There's an open issue MikeKovarik/exifr#90 filed a few years back. One comment suggests returning dates in UTC, another suggests calculating based on offset, and another suggests a workaround to get the string value and do parsing on the client. 🙃

[atombrenner]

Please re-read the MDN doc

A date is represented internally as a single number, the timestamp. When interacting with it, the timestamp needs to be interpreted as a structured date-and-time representation. There are always two ways to interpret a timestamp: as a local time or as a Coordinated Universal Time (UTC), the global standard time defined by the World Time Standard. The local timezone is not stored in the date object, but is determined by the host environment (user's device).

Agreed that returning a string representation of a timestamp would be explicit of the timezone. Maybe in hindsight the decision to autoconvert some exif tags to Javascript Date objects was not the best. Changing it now would break compatibility.

Reading only the first 512 bytes will not return extended EXIF tags. To verify you can use e.g. this jpeg reader that reads all tags from a file.

[martpet]

The date object returned by exif-reader is not correct.

Currently it's built like this:
new Date(Date.UTC(2025, 3, 15, 23, 03, 21))

Instead it should be created like this:
new Date('2025-04-15T23:03:21+03:00')

or
new Date('2025-04-15T23:03:21Z') (when the timezone is missing)

[carpeliam]

@martpet the first and last examples you mention (new Date(Date.UTC(2025, 3, 15, 23, 03, 21)) and new Date('2025-04-15T23:03:21Z')) are equivalent to each other.

[martpet]

@carepalm Yes, they are equivalent. Only my second example is important.

It's not fatal the way it is now, I'm fixing it like this:
new Date(date.toISOString().replace('Z', timezone))

[aarondoet]

Maybe in hindsight the decision to autoconvert some exif tags to Javascript Date objects was not the best. Changing it now would break compatibility.

That is what version numbers are for. Don't do a 2.0.3 or 2.1.0 update with this change, but it could be a 3.0.0 update.

I do agree that it should just be left as a string and not converted to date, I only found out while testing and seeing that a photo with my local 23:44 had 23:44 UTC as timestamp, I would have assumed a date object to use the correct timestamp otherwise.