You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the epoch has a decimal in min_taken_date/max_taken_date/min_upload_date/max_upload_date, the API returns the complete set of pictures instead of the search request.
Such decimal is caused by the hundredth of seconds in the epoch notation.
1527638245 is valid, but 1527638245.75 isn't.
This can be reproduced here: https://www.flickr.com/services/api/explore/flickr.photos.search
Should the epoch automatically be converted to an integer to make sure we are always on the safe side?
Cheers,
The text was updated successfully, but these errors were encountered:
That's really a strange behaviour, it seems the input validation on their side is broken for date fields.
It would be cool to have a way to sanitize arguments to avoid this kind of problem, I think we can have a type field on the objects on methods.py file and do a validation phase before sending the request.
Hello
If the epoch has a decimal in min_taken_date/max_taken_date/min_upload_date/max_upload_date, the API returns the complete set of pictures instead of the search request.
Such decimal is caused by the hundredth of seconds in the epoch notation.
1527638245 is valid, but 1527638245.75 isn't.
This can be reproduced here:
https://www.flickr.com/services/api/explore/flickr.photos.search
Should the epoch automatically be converted to an integer to make sure we are always on the safe side?
Cheers,
The text was updated successfully, but these errors were encountered: