search

jikan-me / jikan

Unofficial MyAnimeList PHP+REST API which provides functions other than the official API
https://jikan.moe
MIT License
897 stars 93 forks source link

Start/end dates don't show precision #486

Open PythonCoderAS opened 2 years ago

PythonCoderAS commented 2 years ago

Manga https://myanimelist.net/manga/516 only has a precision of a year. However, the Jikan API returns that the manga started on January 1 of the year. The only way to find out the difference is to look at the string representation and regex it. I think a new field should be added, where if the month and date are not there then the month and date fields should be null.

irfan-dahir commented 2 years ago

This is the appropriate response we've set it to return.

If there's only a year provided by MAL, then that's the best-estimated precision you can get.

If you need the actual value that MAL returns, that's also passed as a string.

PythonCoderAS commented 2 years ago

This is the appropriate response we've set it to return.

If there's only a year provided by MAL, then that's the best-estimated precision you can get.

If you need the actual value that MAL returns, that's also passed as a string.

My problem is that there is no easy way to distinguish between "2003", "Jan 2003", and "Jan 1, 2003". All 3 would show the same values unless I parsed the human-readable string. I need to know this because the way I am using the data, the other platform allows month/days to be null, so it's important to leave those null when it's a guess.

ToshY commented 2 years ago

My problem is that there is no easy way to distinguish between "2003", "Jan 2003", and "Jan 1, 2003". All 3 would show the same values unless I parsed the human-readable string.

Before I used Jikan, I've faced this issue as well, and because I agree that 2003, Jan 2003 and Jan 1, 2003 are 3 different things, I created a workaround solution for it back then. So after finding it again, and concluding it hasn't really aged very well, it still seems to work. I will rewrite it, and if you're still interested, post the snippet here.

... the other platform allows month/days to be null, so it's important to leave those null when it's a guess.

I'm not sure which "other platform" you're referring to, but I've seen AniList's GraphQL having separated the properties year, month and day as well, also being nullable.

@irfan-dahir Related to this issue, there currently is no property in the Anime model which allows to get the raw airdate string. So I would suggest adding a property there, which can use the the getAnimeAiredString from the AnimeParser. If you're okay with that, I can make the PR.

PythonCoderAS commented 2 years ago

Could you share the snippet? I have a solution that seems to work but has some edge cases (like when an end date is missing)

ToshY commented 2 years ago

@PythonCoderAS Here's a (updated) snippet, let me know what you think. Think most test cases seem to work, but I don't think it deserves the beauty prize 😄

PythonCoderAS commented 2 years ago

@ToshY thanks but your snippet is in PHP while I'm working in Python. I appreciate it though so I can get at the edge cases.

ToshY commented 2 years ago

Well... it's a PHP library after all 🙃 Anyway, hope you can figure it out too 👍

irfan-dahir commented 2 years ago

@ToshY responded within PR

@PythonCoderAS If I were to make changes here to allow for nullable, I'd change the default behavior of aired.prop rather than add a new property so it doesn't return an estimation and rather just null.

However, one issue is; the start_date and end_date properties are ISO8601 formats and they need day/month. Their values would be different from aired.prop (as it will force estimation to fit in the DateTime format)

ToshY commented 2 years ago

@irfan-dahir Seems that the Person model also has a getBirthday() which returns null when a person has a birthday format of Y (example) or M Y (example). Is it possible to add unparsed here as well?

PythonCoderAS commented 2 years ago

@irfan-dahir That was my original idea but won't it cause a breaking change?

irfan-dahir commented 2 years ago

Hmm, kinda. Tho, these are very minor edge cases where the date isn't fully provided.

irfan-dahir commented 2 years ago

@ToshY yes, but that would be a breaking change as it's not a date range and the data type would change.

We'd probably have to introduce a new object that handles dates and timestamps specifically. So it could perhaps return both parsed info like ISO8601 and props and the unparsed date string. And have every date/timestamp property return that object.

But these minor edge cases are only in a few areas where dates are often estimated or incorrectly entered like anime or a person's birthday (for some reason 😅)

github-actions[bot] commented 1 year ago

This issue will be closed and archived in 18 days, as there has been no activity in the last 60 days. If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.

PythonCoderAS commented 1 year ago

Bump

github-actions[bot] commented 1 year ago

This issue will be closed and archived in 18 days, as there has been no activity in the last 60 days. If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.

pushrbx commented 1 year ago

bump

Prid13 commented 10 months ago

Hey, any news on this issue? Just realized this was a thing when I noticed how "Isekai Suicide Squad" showed start date as "January 1, 2024" in my app, making me think it had started, only to realize the date was only officially set to "2024" and leaving disappointed to try and search for the cause 😅