Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] The times are not the times #207

Closed
KenEucker opened this issue Dec 10, 2023 · 3 comments · Fixed by #216
Closed

[BUG] The times are not the times #207

KenEucker opened this issue Dec 10, 2023 · 3 comments · Fixed by #216
Labels

Comments

@KenEucker
Copy link
Owner

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:

  1. 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.
  2. 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!
  3. 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:

  1. 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.
  2. It can be stored in the title. We have a space there.
  3. 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".
@KenEucker
Copy link
Owner Author

KenEucker commented Dec 18, 2023

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 ].

KenEucker added a commit that referenced this issue Dec 22, 2023
…ur image in a readable format

all new BikeTag image descriptions will include this string at the end " on [x/x/x@y:y:y]"

resolves #207
@KenEucker
Copy link
Owner Author

Ended up going with tag #34 found at () by sonso on [x/x/x@y:y:y]

@KenEucker
Copy link
Owner Author

🎉 This issue has been resolved in version 3.2.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
1 participant