Error with date 0 / 1970/01/01 00:00:00

[jackb_guppy]

Setting create date and time with avcont. 

If set to 1970:01:01 00:00:00, first instance of Jan 1 1970, exiftool returns 0000:00:00 00:00:00, which would match up to 0 in unix/linux timestamp.

Version is still 10.07.

[Phil Harvey]

For some date/time values, ExifTool treats a zero value as special, and returns 0000:00:00.  This is because some software fills the field with zeros, and it could be misleading to return 1970:01:01 in this case.

- Phil

[jackb_guppy]

Could there be a flag that changes the default to use a "continues" date/time system?  a kin to the QuicktimeUTC, or force exiftool to use astronomical/http://aa.usno.navy.mil/data/docs/JulianDate.php so there are no "Y2K" type of issues?

Note: JD dates change at noon (hence 0.5 of a day for midnight) so older telescopes don't glitch at midnight for tracking..  There is an modified JD that subtracts 2400000.5 from JD http://aa.usno.navy.mil

Also sorry, i am touchy about poor date handling.  My first Y2K work was done in 1982.  Continues date/time work was 1984.  So I do not expect to find these issues in today's coding.  One of first issues I had to work around was a bug with in date time operations of an IBM OS and how fast it "carried a the 1".  Midnight crossing glitch.  day1 23:59:59, day1 00:00:00, day2 00:00:00.    That messed up interfaces and caused nightly rettraining (excessive I/O  was the cost).

[Phil Harvey]

I don't see the problem.  The system is continuous except for the special value of zero, which ExifTool displays as 0000 instead of 1970.  Chances are that software writing an integer value of zero doesn't really mean a date/time in 1970.  Note that an integer value of 1 will show up as "1970:01:01 00:00:01".

- Phil

[jackb_guppy]

Then your tool is broken for my needs. Yes I can code around all the breaks, and I have started to so I could continue with 10.07, which means going tp 10.08 makes more testing to be sure it still working correctly on 10k objects.At which point getting yjr data myself would lead to more stable code, after initial cost of doing it..

Thank you for the time and effort, I am seeing that metadata is not worth it. A separate database that stores meaningful information is better for long term usability. Meta is nice start, but broken by design for long term.  May shotwell will be better since it keeps a database.

Lastly meta is misnomer here. Since it is part of image file, it is just data, just as comma seperated ;ist is just data. Meta would be if you are in the image or stream, than it is meta.  Just like directory info in the directory element is meta to the file it points to.

Oh well bye and thank you for listening.