Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darichman]

And no I'm not asking for romantic advice

I'm using .395 and I've noticed some date irregularities with images. I think this may have to do with recent changes to how MC deals with dates internally.

1. Irregularities entering dates
For example: If I have a photo shot on 1/11/1913 (1st of November 1913)

If I enter "November 1913" into the Date field it fails to save completely (I get "unknown date")
If I enter "1/11/1913" it saves as "11/1/1913" -- not what I'm after

I'd rather not have to enter Month and Year separately - I prefer to use the date field directly. Both of these examples worked fine a few weeks back

2. If my date field is empty, rotating the image from within MC resets the date field to 1/01/2000 1:00 AM this is a real pain, because I clear all the dates in my scanned images so I can enter the real ones. MC keeps setting the date to 2000 instead!

I'm not sure which build first introduced this but I know this was working fine a few weeks back

Please fix soon! I have a lot of scanned photos I want to tag before I go away for Christmas, and at the moment I can't trust MC to handle dates!

[Matt]

Thanks, we'll take a look.

[darichman]

Thank you Matt

[John Gateley]

For example: If I have a photo shot on 1/11/1913 (1st of November 1913)
If I enter "1/11/1913" it saves as "11/1/1913" -- not what I'm after

What is your locale? If it is default, I'd expect 1/11/1913 to mean January 11, 1913. This is the U. S. default.
If your locale is set correctly, I'd expect it to do what you want. Let me know what your language setting is, and I'll give it a test.

j

[John Gateley]

If I enter "November 1913" into the Date field it fails to save completely (I get "unknown date")

This is "correct" behavior, though not what you want. We cannot parse a date that does not include the day.

If you enter "November 1, 1913", you'll get what you want.

j

[darichman]

John, thanks for the post.

What is your locale? If it is default, I'd expect 1/11/1913 to mean January 11, 1913. This is the U. S. default.
If your locale is set correctly, I'd expect it to do what you want. Let me know what your language setting is, and I'll give it a test.

My locale is Australia. My language is English. The system default date format is DD/MM/YYYY. This has not changed recently in my system, but MC has in recent builds.

Assuming you're right and I have to use the MM/DD/YYYY format, the following still happens
   ... if I type in 14/11/1913 it works (I still get 14/11/1913 and there is no 14th month)
   ... if I type in 3/11/1913 I get 11/03/1913 (Month reports as March)
   ... if I type in 11/3/1913 I get 3/11/1913 (Month reports as November)
   ... if I type in 7/11/1913 that's what I get (expected)

This is inconsistent whatever the locale settings, and whatever the system locale is set to, shouldn't I still get what I type in? (as long as the month is 12 or less)

This is "correct" behavior, though not what you want. We cannot parse a date that does not include the day.

You used to!! I can 100% attest that not all that long ago in MC if I typed a month and a year (eg March 2003) into the Date field, it worke fine and automatically assigned the Day as 1. I have tagged hundreds of scanned photos in this manner, when you don't know the day, but you know the month and the year.

So it appears I've lost some functionality I have a feeling all this changed in a recent build (I can't find the summary of recent changes or I'd give you the build # -- I know the change went something like "changes to how MC deals with dates internally")

Thanks for looking into this

[leezer3]

That would have been 12.0.376
I agree that you should be able to enter solely a month and year in the date field, and in this situation IMHO it'd be better if it was possible to store dates without a day. (Don't know the database ramifications for that though?!)

-Leezer-

[John Gateley]

Assuming you're right and I have to use the MM/DD/YYYY format, the following still happens
   ... if I type in 14/11/1913 it works (I still get 14/11/1913 and there is no 14th month)
   ... if I type in 3/11/1913 I get 11/03/1913 (Month reports as March)
   ... if I type in 11/3/1913 I get 3/11/1913 (Month reports as November)
   ... if I type in 7/11/1913 that's what I get (expected)

If we get a month larger than 12 and a day in the appropriate range, we assume something is mixed up and swap the two. That's why 14/11/1913 reports as day 14, month 11, year 1913. The other 3 are correct.

There may be a problem with recognizing your locale, I'll check this tomorrow now that I know what to set it as.

What does "November, 1913" mean? Does it mean November 1st, 1913? November 1-30, 1913? Some random day in November?
I can implement the first one (or the third ), but I don't want to unless there is a compelling reason to. Date parsing is complex, and the more cases you allow, the more potential for something unexpected to happen.

j

[darichman]

Thank you John

The other 3 are correct.

I'm not sure I follow... Whatever my locale is, if I type in 3/11/1913 why should it swap it to 11/3/1913 ?
I could understand it thinking I'm putting in MM/DD/YYYY when I'm intending DD/MM/YYYY, but even then it would still show as 3/11/1913 -- but it would just think it was the 11th of March and not the 3rd of November

I'm a little confused. Either it's thinking I'm inputting the date into the MM/DD/YYYY format and trying to correct it to my locale (DD/MM/YYYY)
...or it's doing the reverse: it's turning it from DD/MM/YYYY to MM/DD/YYYY for some reason
Whatever it's doing, it is definitely swapping the format
Digital photos with timestamps and previously tagged photos still show the correct date in the DD/DD/YYY format (what I want), so this is a problem simply with inputting the date not displaying it.

What does "November, 1913" mean? Does it mean November 1st, 1913? November 1-30, 1913? Some random day in November?

November 1913 means I know the photo was taken in November of 1913 but I have no way of knowing the exact date. So I guess your last option. If I don't know it's November 1st, I'd rather not enter a "1"

I'm not sure what the correct behaviour should be... with digital photos we always know the day and usually the time...
With older scanned photos we may only know the month/year or only the year

If I enter a year only... should MC just assign it as 1st of January [That Year] ... or should it leave the month and day alone, because we don't know them
If I enter a month & year... should it assign it as 1st of [That Month] ... or should it leave the day empty because we don't know it

I don't know enough about how MC handles dates now to know how it can/should behave...

Only the standard date fields have this conversion logic. Internally MC uses always this "seconds since January 1st, 1970" system.

Is this still the case? If so, I understand the need to have the day and month filled in (usually as "1") as you need to generate a single number in seconds since 1/1/1970
If not, ideally I'd like to be able to just enter the information I actually know (ie JUST the year or JUST the year & month)

Ideally I would like to be able to leave a day empty or a month empty if I don't know them. This would allow dates of February 2004 as opposed to 1st February 2004
Currently, if a photo is listed as 1/12/1995, I don't know if it is actually the 1st of December or just a photo labeled December that MC has automatically assigned a day of "1" for

If a date is listed as 1/1/1976 ... it gets more complicated
   Is it New Year's Day 1976
   ...or is it some random day in January of 1976 (don't know day)
   ...or is it some random day in 1976 (don't know day or month, just year)

Whatever the changes have been internally... the old system used to work for me, and this one doesn't at the moment

I hope I'm explaining myself okay
Thanks again

[darichman]

Sorry double post

[John Gateley]

Perhaps I'm confused: let me check tomorrow. There may be a locale problem where in one case we're doing the right thing with respect to the locale, and in another case we are ignoring the locale.

I don't know how we're storing dates internally: whether they are actual dates or ranges or what. I'll talk to Matt tomorrow, but probably "November, 1913" is going to be invalid...

j

[darichman]

...but probably "November, 1913" is going to be invalid...

Yes, you're right. It is currently, but it didn't used to be. This is not so much an issue for me as the date format switching though

[Alex B]

Unfortunately, that is not possible. Only the standard date fields have this conversion logic. Internally MC uses always this "seconds since January 1st, 1970" system.

Is this still the case? If so, I understand the need to have the day and month filled in (usually as "1") as you need to generate a single number in seconds since 1/1/1970
If not, ideally I'd like to be able to just enter the information I actually know (ie JUST the year or JUST the year & month)

That system is used with the Date Imported, Date Modified and Date Created fields. The Date field is stored in the following format.

The Date field seems to be a day counter.

- the number 1 represents December 31st, 1899
- the current date is 39124 (February 11th, 2007)
- December 30th, 1899 would be zero but that is not possible with the used logic and MC doesn't accept this value.
- December 29th, 1899 and older dates use negative numbers starting from -1
- if only the year number is inserted in the Date field MC stores the date as January 1st of that year.


I tried to find a reason for the odd looking December 31th, 1899 date. Why isn't it January 1st, 1900? Looks like this is the explanation:

And finally, why 30 December 1899? Why not, say, 31 December 1899, or 1 January 1900 as the zero day? Actually, it turns out that this is to work around a bug in Lotus 1-2-3! The details are lost in the mists of time, but apparently Lotus 1-2-3 used this date format but their devs forgot that 1900 was not a leap year. Microsoft fixed this bug by moving day one back one day.

That blog explains some other date related oddities too.

The numbers after the dot are just digits after the decimal point. For example,
37808.5 results 7/6/2003 12:00 PM  and  39232.618055555555 results 5/30/2007 2:50 PM

[darichman]

That system is used with the Date Imported, Date Modified and Date Created fields. The Date field is stored in the following format.

Ah thanks for clearing that up Alex

[Alex B]

I would like to add that obviously MC uses only this single internal value for the internally stored date. Everything you see on the screen is calculated from this value.

For example, when 2003 is inserted in the Date field it is internally stored as 37622 (= January 1, 2003). This value can be displayed in several ways depending on the OS locale and MC's internal translation.

[John Gateley]

Found a problem. It turns out that Jan 7, 2007 is represented in Australia as 7/01/2007 and I was expecting 7/1/2007. This caused the date parse to revert to the U. S. standard, and hence the confusion. Fixed in build 397.

j

[darichman]

Thanks for the quick fix!