1899-12-30 date

[sinus]

Hmmm, I have to check this out, but unfortunately I have not the time now.

In reference to this thread
https://www.photools.com/community/index.php/topic,12552.msg88888.html#msg88888

I wrote this:
Just a short update:
After my personal, not experienced tries, you, Mario, are correct with 1700.
1700 should be safe.

In my tries, I found out, that the border for safe dates is the year 1601.
1601 works but 1600 and even more back works not more.

This means, that the 1700, what Mario wrotes, should be really safe.
Maybe it is also safe until 1601 back, but for sure you will get problems, if you do write dates from year 1600 and earlier.

This worked really very good. Now, with the new 2023-IMatch, I did this again, the first time, like before.
But if I enter in the metadata tag (like I did before), in the tag {File.MD.XMP::photoshop\DateCreated\DateCreated\0}

1601:01:01 01:01:03+02:00

Then I rename the image and curious I get the date of:

18991230, means 30. Dez.1899 in my filename, before 2023-version it was a filename like
16011013

It seems to me, like the date 1899 (30.12) is something like a border.

Mario, this is not important. I have now really unfortunately no time to check further. 
Hence only my question, does this date (1899-12-30) means something special to you in relation to the new date-times in 2023?

If yes, fine.
If you have no clue, let it be, I will then check further in some weeks with better infos for you.

[erichaas]

I have no need of dates this early, but I tried this out of curiosity.

Entering 1601:01:01 01:01:03+02:00 gives me 18991230 when I rename it.

Entering 1601:01:01 12:00:00-04:00 gives me 16000101, as one would expect.

My guess is, the first time stamp converts to 1600:12:31 23:01:03+00:00 in UTC. Since 1600 is not within the valid range, it gets replaced by 0 (zero), and for SQL a date of 0 is Dec 30, 1899.

[sinus]

Hi Eric, you are completely right!

Thanks a lot, very good, this is, I think, the answer.
For me was a bit the thing, that entering 1601 before IMatch 2023 worked perfectly, now not more.
And 18991230 was mysterious for me, though I guessed, it is some standard date.

Now I checked again, and it works again!
And this makes (for me) completely sense:

I entered this:
1601:01:01 01:01:03+02:00

In Switzerland we have now summertime. 
This makes my date before 1601, means 1600...

And like I tried in my other (old) post, dates with 1600 works not, with 1601 works.

This is still valid.
My error was, I did not think at the +02:00 from the summertime. 

If I change the time to 
1601:01:01 02:01:03+02:00

it works again.

Problem solved, thanks, Eric!

[sinus]

BTW: 
I wonder, what and where people write dates from centuries before 1600.
And even before Christ (BC) 

430 years before christ

and how and where writes people in the astronomic world dates like the age of stars ...

500 millions years  
13.8 billion years

Hm, do they have special metadata-tags? 
If I have time, I will look for this, just out of curiousity. 

[Mario]

As you've found out, the problem is the +02:00 time zone offset you've added.

Starting with the time stamp 1601:01:01 01:01:03+02:00, IMatch emits these variable values:

Code Select Expand

{File.DateTime}
{File.DateTime.UTC}
{File.DateTime.Local}

01.01.1601 01:01:03
 23:01:03
30.12.1899 00:00:00
because you produce a time stamp before 1601 and this is not valid for UTC and not supported by the calendar and time routines IMatch uses to calculate date and time, transform date and time etc.

Note: The time stamp is written and re-read correctly to the XMP record.

Changing the time zone offset to 00:00 or changing the date from 1 to 2 to avoid hitting the year 1600 works.
For 1601:01:01 01:01:03+00:00, the variables emit:

Code Select Expand

File.DateTime:       01.01.1601 01:01:03
File.DateTime.UTC:   01.01.1601 01:01:03
File.DateTime.Local: 01.01.1601 02:01:03

You will also run into problems when you try to enter date and time outside the supported range in the Metadata Panel, like a 1500 date. The routines which parse your input and transform it from text into a date for validity and range checking, adding a time zone when it is missing etc. also don't support dates before 1600.

IMatch is not a DAM designed for archeologists or persons dealing with images showing subjects created before 1601.
Dealing with that would require to abandon use of the C++ and Windows time and calendar functions I use, the time database, built-in calendar controls and date/time formatting for local formats and to rebuild everything based on "something" that can deal with years before 1601 and then implement everything from scratch.

Looking at the zero requests for this kind of date management and the amount of work involved, I'd say I'd look into this when there comes in a ton of requests or I can sell 1,000 licenses for IMatch to an archeological society or institute

You can store info that the image shows something from 500 million years ago in any XMP user text field or as a text Attribute.

[sinus]

Thanks, Mario
VERY interesting. I see, you have all these stuff in mind and knows, how to deal with it. Great.

1'000 licenses for IMatch ... hmm, if I would be a multi-millionaire, I would buy these licences, but unfortunately, I am sorry ....  

About store 500 million years and others, I am sure, I will find a solution with IMatch, what works for me. I am very sure, because I can do such a lot things with IMatch. 

[erichaas]

BTW:
I wonder, what and where people write dates from centuries before 1600.
And even before Christ (BC)

430 years before christ

and how and where writes people in the astronomic world dates like the age of stars ...

500 millions years 
13.8 billion years

Hm, do they have special metadata-tags?
If I have time, I will look for this, just out of curiousity. 

People working with dates hundreds of thousands of years in the past, or more, generally don't need calendar math. They could just use a real number field to store the approximate dates.

But working with more recent dates before 1800 can be tricky, because of the switch from the Julian calendar to the Gregorian calendar. This took place at different times in different countries. It's something genealogists have to deal with on a frequent basis.

[sinus]

Thanks, Eric, for your input!

I will see, what I can do to deal with this.
My goal is quite simple: I do quite a lot of timelines, based on the real date. This is nice for personal, privat use with family and friends events. 
And also very interesting for a business timeline. 

For this I use special categtories and do outputs (at the moment) with Design & Print.

In the next time I will do such timelines with first historical stuff back, say to the egytpians.
And then another one with astronomical stuff, back to the big bang.