[BUG] The times are not the times
Closed this issue · 3 comments
Describe the bug
The times (and dates, for that matter) for the BikeTag API data are simply the times of the upload to Imgur. This does not necessarily reflect the time that the tag was acquired. While it may not be as important for some things, having accurate times are important for the following reasons:
- timezones are not reflected. the time that is displayed is whatever time that Imgur chooses at the time of upload. Example: Vienna's times are not reflective of the time of day that the tags were obtained.
- When images are deleted and reuploaded, which happens sometimes, or when entire albums are copied to new locations, which has happened a couple fo times to overcome issues created by Imgur that were not resolved: the times are then the time of upload. More than half of Seattle's current tags were all done on the same day!
- We cannot use any of the time data for things we might want to do in the future (like badges).
Additional context
This was a tough one for me to crack, mentally. I think the solution I prefer moving forward is this:
- Keep it human-readable. We can do MM-DD-YYYY HH:MM:SS if we want to, or some shortened version of that, and still be able to display it in any format for a given locale.
- It can be stored in the title. We have a space there.
- The shorter the better. As we add more text data to each tag, we increase the amount of data to receive on the "ONE BIG REQUEST".
Coming back to this to say that the mysteryTime value should play a role in knowing whether or not a tag has been posted. For queued tags, if the mysteryTime is blank then it hasn't been posted yet.
Also, instead of adding it to the title, it should just go in the description. tag #34 (hint:) by sonso [@ 3:11pm on 11/12/23] and tag #34 found at () by sonso [ @ 4:20pm on 11/12/23 ].
Ended up going with tag #34 found at () by sonso on [x/x/x@y:y:y]
🎉 This issue has been resolved in version 3.2.0 🎉
The release is available on:
Your semantic-release bot 📦🚀