Bug report - Event seems stuck in 'just now'

[cat]

An event appears to be stuck at the top of the feed as ‘just now’

I noticed Arctagon’s event showed after I submitted my update, went and poked around at other things, came back to the main page and saw it was still ‘just now’ but along with the event below it in the screenshot. I waited a bit, refreshed the page, and there it is still. I vaguely remember something like this happening before, I wanna say it was due to time zones?

Trello link:

[brandon]

Yeah it’s a timezone issue and I haven’t yet thought of an elegant solution to solve it… outside just handling timezones better

Basically, the servers are on east coast time. Sometimes, people in East Asia log their books in the morning, so the next day from the east coast perspective, and they manually mark the book start date as the next day.

Accordingly, it hangs at the top until East Coast reaches the next day, which is 1PM Seoul time. So a pretty big time lag.

I should try to do something about it… I agree it’s really annoying…

[brandon]

Approved. Will try to figure something out.

[cat]

Spitballing but could you add a column for date added (server time) and date added (display time)? Server time being used only on the feed for ordering events in the background, and display time being used well… For display.

[seanblue]

Times should generally be stored in UTC and converted on the browser to avoid issues like this. In this case, there’s also manually entered dates, which should be local time (i.e. if you say you completed a book on 7/10, it should always be 7/10 regardless of time zone it’s viewed in) and shouldn’t be relevant for when/where to display the activity in the feed. But in the case of when the activity was added, that should be UTC so it’s consistent no matter where the user is located.

[Megumin]

I think if for some (valid?) reason, people are allowed to enter activity in the future, it should only be displayed to that user until the time inputted is the actual time.

[seanblue]

@Megumin

I think if for some (valid?) reason, people are allowed to enter activity in the future, it should only be displayed to that user until the time inputted is the actual time.

My point was, that shouldn’t matter. It should appear in the activity feed based on when it was entered, not based on the inputted date. I just tested it by setting a book as completed yesterday, and it was indeed added to the feed as “18 hours ago” which makes no sense.

[Megumin]

Well then I’d put two dates, one submitted and one actual time, because past dates do make sense IMHO, unlike future dates which I still don’t see the logic.

I might have read a book yesterday, and forgot to record, and still want to record it with yesterday’s date.

[seanblue]

Yes, we’re in agreement. The activity feed date and the submitted date should have no connection to one another.

[brandon]

@seanblue

Times should generally be stored in UTC and converted on the browser to avoid issues like this. In this case, there’s also manually entered dates, which should be local time (i.e. if you say you completed a book on 7/10, it should always be 7/10 regardless of time zone it’s viewed in) and shouldn’t be relevant for when/where to display the activity in the feed. But in the case of when the activity was added, that should be UTC so it’s consistent no matter where the user is located.

Yes that’s the general solution and I agree that should be the case. It’s just I’d need to correctly handle the timezoning wherever I surface dates & edit dates, which isn’t super trivial… it’s a little work. I’d also need to handle stats appropriately.

All very doable, but I’d love a quicker fix for this bug, if possible. Perhaps not though