New post showed in 0s

[jsoref]

I posted a toot reply in Tusky test:
https://mastodon.social/@jsoref/109354279474109468
It rendered with a in 0s time.

Expected: don't report ~+0.... s as that, for some ε from now, use now.

For things significantly in the future, a lot of work should be taken, so let's leave that out of scope.

---

• Tusky Version: Tusky Test 19.0-a9c6f695

• Android Version: 12

• Android Device: Pixel 3A

• Mastodon instance (if applicable): mastodon.social

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[kylegoetz]

created a PR for this #2843

[connyduck]

@kylegoetz if you write closes #2842 in your PR GitHub will automatically link it to the issue

[kylegoetz]

I've tested it a few times in a live environment, and the util that calculates the display value is sometimes passing in spans that are less than -2000. Is there ever a time when the timeline should allow this? Would it be easier to just say, before calling the TimestampUtils to determine display string, say "if it's negative, then set to 0"?

When I created a new status and logged out the TimestampUtils.getRelativeTimeSpanString output, I get

[snip] D/TimestampUtils: then: 1668641427425; now: 1668641424989; span: -2436

Seems like a server/app time not being perfectly in sync or something. Would it make sense to just put in the adapter that displays notifications to say "if the span is negative, set it to 0"? Note: this would not be a rule in the util, but in the util caller (I think this is NotificationsAdapter but haven't bothered to dig in here yet to make sure it's this particular class).

[jsoref]

If the offsets are really off, one of the systems times is probably out of sync with the world. It could be the remote server or the local client.

For that case, it's helpful to explain this to the user. I added code to Mozilla/Firefox for this years ago. But it's a lot more work, which is why I hinted at it in my ticket and suggested leaving it out of scope.

[kylegoetz]

So I guess that's a UX decision: at what point is a "in the future" so big that you should alert the user vs silently "correct" a small "future" to "now" and just keep it "now" for those few seconds?

I'd propose something like five seconds. Anything less in the future, does the user really care to see an accurate span calculation? If it's a network lag issue[1], and it's just related to a user immediately after creating their own tweets, should we just use the device's now and ignore the server's response after tooting, which would mean we never will have a negative value to worry about.

---

[1] I'm unfamiliar with how network latency + timestamps are handled with Mastodon API - is created_at based on client sending a device now or is it based on the receiving server storing in the DB with a server now value?

[jsoref]

I can't remember what our thresholds were for browsers. Being off by a few minutes really isn't terrible.

A quick check shows that it's basically "Is the clock set to before the date of the build of the program that's running?"

Typically the problem is that a computer's CMOS battery is dead (and the main battery runs down) and thus when the device turns on it boots to its birth date which is typically many years in the past. Sufficiently far in the past that most intermediate CAs aren't valid yet (or something like that) and certainly that pretty much every web server's certificate wouldn't be valid yet. These devices typically aren't set to sync to a network to get time. There are variations on this where instead of the user's device having a faulty battery, an Internet-[DevIce]-of-Things (IdiOT) has a faulty battery, is discontinued by the vendor and either was using a vendor's time server (which was also discontinued) or misused a public time server w/o prior agreement (due to a series of bugs in their NTP client) resulting in the public server banning their devices and blocking them.

Anyway, that's a long winded way of saying, that while on average the fault is the client device, it can be the server (or the server could be evil, which is the really fun case).

Here's firefox developer edition's message:

Your Computer Clock is Wrong

Your computer thinks it is Nov 16, 1990, which prevents Firefox Developer Edition from connecting securely. To visit www.cbc.ca, update your computer clock in your system settings to the current date, time, and time zone, and then refresh www.cbc.ca.

The link is to:
https://support.mozilla.org/en-US/kb/troubleshoot-time-errors-secure-websites?as=u&utm_source=inproduct
And conveniently, they're smart enough to include a local version (since obviously that server isn't reachable either for the same reason):
chrome://global/content/neterror/supportpages/time-errors.html

And here's chrome's:

Your clock is behind
A private connection to www.cbc.ca can't be established because your computer's date and time (Friday, November 16, 1990 at 9:46:56 PM) are incorrect.
NET::ERR_CERT_DATE_INVALID

Anyway, that's a long winded way of saying that the real "off by a large magnitude" thing should be handled elsewhere.

---

For this, 5s into the future or even 59s into the future are perfectly fine "now" values for me. I don't really care.

At the +1h (+/- a couple of minutes for jitter) into the future, you start getting into the "oh, someone's clock and time zone aren't properly configured" (this still happens often enough -- my TV generally gets incorrect time zone related directory announcements for months after the DST transition). At +48h into the future, someone's clock is dead wrong.