Hi Mike;

You are correct! Some data items DO have just a year and as I am using your wrapper it's a problem. I think this a result of a latency of old records. Travis seems to add new fields and populating them with stuff-and-things. The latest which I have run analysis on are Original Language stuffed with "English" regardless of production country and spoken language for some 29000 plus records, and "Video" all turned off by default (not so bad and understandable as it's a boolean). So... Is your solution then to provide all the date types as objects and let us TMDBLib users sort it out in our apps?

Regards; Joe

I have yet to figure out how to do it. The discussion will take place on GitHub, and some solution will be found.

Hi guys,

No, this is not expected. Like Mike said, it's probably left overs from the old editing interface. I thought this field had some validation on it but it doesn't, so I'll have to get that added. Ticket for that is here (there's some other sanitizing I need to do on names as well.)

I'm not sure what to do with these fields, I might just have to delete them since the only real thing to do would be to default them to YYYY-01-01 but if we do this, they will never get fixed.

Thanks.

Travis, the discussion at https://github.com/LordMike/TMDbLib/issues/68 led to this comment: "[..] I wish the movie & TV release date were setup this way instead of having to input bogus information when the exact date isn't known [..]".

And I kind of agree with him. It'd be sad to input bogus information.. which is why I started an effort to support the year-only dates. If other clients can handle it too, maybe it'd be ok to have year-only dates?

Hi Mike,

For a field that is less of a fact and more "wishy-washy", I probably agree with you but for something like birthdays, they are not wishy-washy at all and are always indeed, a day, not a year. That's my issue with this. No one has ever been born on only a year...

Regarding birth and death dates, it depends. For movies and TV, you probably won't be going back hundreds or thousands of years, and therefore it should be possible to recover all the exact dates. But I suspect that there may be more than a few, where Wikipedia and other sources just cite the birth/death dates as "sometime around year XYZ" or perhaps "spring in year XYZ"..

Mike and Travis;

I setup two fields in my database, one for the movie_ year (integer) only in the movie record and the other for the release date (date) in the movie_releases record.Then I can search/etc. as needed. This seems to be a reasonable solution as I can validate on (integer) (range) or (date) as required. This would be consistent with "original language" and "spoken language" logic. To populate my movie_year field I used year(release_date) if the latter validates as (date).

Regards; Joe

To continue. Person #702 is recorded on IMDb (http://www.imdb.com/name/nm0848883/) as being born in 1960, but without a day.. So for his and possibly many of the other 2200 persons without correct dates (https://docs.google.com/spreadsheets/d/1LGIlLxXEkb2g9zLVeESBFB41-UVZk_wAnod31QV1K5Q) might just be "erased" (their dates set to null)..

For movies and TV, you probably won't be going back hundreds or thousands of years, and therefore it should be possible to recover all the exact dates.

A quick query shows the earliest movie with a release date of "1874-12-09", so ya, not that far back ;)

With regards to recovering the exact dates, I'm not positive by what you mean. We don't have any way of scraping (nor would we want anyways) other sources for this information. I can either snap them to YYYY-01-01 or delete them. Missing information will often yield updates and fixes faster by the community whereas of course, by choosing YYYY-01-01, it's unlikely they'll ever get touched again.

One last thing, I can leave it be, and simply add the validation that it's an integer and 4 digits or a valid date. But then you (and everyone else) will indeed have to support the 2 fields types in one.

Nah. My vote's with the wiping and community fixing. It's cleaner.

Travis;

Please read my comments on Mike's Github regarding date entries:

https://github.com/LordMike/TMDbLib/issues/68

Please do not destroy any date entries even though they are wrong (ie year only). If needs be put them aside for now please.

Joe

@ Joe Rose Please stop to delete the birthday years until the admin makes a decision how to go on