Skip to main content

Unpopular opinion:

Websites should never show timestamps as "x minutes/hours/days ago" but should always show timestamps as LITERALLY THE ACTUAL DATE AND TIME

because otherwise, 1) you have no clue when any event actually happened, it depends on "when did the server/client refresh this page" and 2) when you're scanning for "literally a date/time" string, you can't find it and it's so frustrating.

Oh and ALWAYS include the timezone or it's still nonsense.

Thank you for coming to my TED talk.

Mark doesn't like this.

in reply to Nate Cull (.social)

Nate Cull (.social)
Nate Cull (.social)
• •
To be clear, what I mean by "timezone" really is UTC offset.

So I'd like to see all timestamps appear at least something like this:

2022-04-30 19:53:00 +12

because without the offset it's not an unambiguous time. Could be off by up to 24 hours.

I don't actually do this myself, because I'm a bad person who doesn't do what I hope other people will do.

But yeah, I'd like all clock readouts everywhere to be 24 hour and show the UTC offset just as a matter of course.
in reply to Nate Cull (.social)

Nate Cull (.social)
Nate Cull (.social)
• •
I don't even know WHAT the deal was with 12-hour clock dials in the first place.

I guess someone in the Roman era went "well, this sundial's obviously only gonna work during the day, so I can optimise and cut the amount of stone required by 50%!" Which was very sensible.

And then when gears were invented, and the clock face became round, everyone just ran with 12 hours because of legacy compatibility reasons?
in reply to Nate Cull (.social)

Nate Cull (.social)
Nate Cull (.social)
• •
None of this time stuff would ever have been a problem if it wasn't for the telegraph and the railroad.

I think we can all agree that those two inventions are probably responsible for everything bad that's happened since.
in reply to Nate Cull (.social)

Rick G aus N
Rick G aus N
• •
My take is the inventors of the clock dial came from an era where time just did not matter. Before industrialization and railroads which required punctuality and timetables, days would start at dawn and everybody would settle in at sundown. They would make appointments like "three days from now when the sun is at the highest point". Everything that required planning, working, scheduling happened during the day. A 12 hour clock was perfectly sufficient
Unknown parent

Nate Cull (.social)
Nate Cull (.social)
• •
Yes to that first sentence, but no to the second.

It's trivial for a computer to store timestamps in UTC, though often it's much harder than it should be to tell if a given timestamp IS in UTC or not.

But a server has no good way of knowing what time zone I'm in. It can check what I told it once when I created my account, or it can try to guess from geolocating my IP address, and both of those can be very wrong. And even my client might not know either - eg if I'm travelling.
Unknown parent

Naich
Naich
• •
Both the server and your computer are capable of storing the time and date in a universal format and then converting it to your local time. They both know which time zone you are in.
Unknown parent

Naich
Naich
• •
All those things can be done on the server.
Unknown parent

Nate Cull (.social)
Nate Cull (.social)
• •
I mean, by "timezone" I would certainly accept "UTC +x". Probably much better than doing the abbreviation thing.

But not just "3 days ago" or "2022-04-30 11:53pm" with no indication of how many hours that is away from me.

It's *maybe* okay to just report all times in my local timezone. Probably makes most sense to. BUT!

If I screenshot or copy and paste a timestamp string, and you read it two years from now in a different timezone, you probably want it to be unambiguous.
Unknown parent

Nate Cull (.social)
Nate Cull (.social)
• •
"so, instead of knowing when something happened i'm supposed to 1. know how timezones work"

Yes.

You live on a globe. Therefore, you need to know that other people - maybe who you're talking to right now! - live in other timezones.

This is perhaps more obvious for people like us here in New Zealand where we're *always* interacting with people not in our own timezone. In the USA, *maybe* you can get by without caring about timezones? But here, we can't not care.
Unknown parent

Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)
Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)
• •
🍬 I see a tension between use as an end user and use as an administrator or auditor. For end users, who presumably know that the page was loaded recently because they’re the one who loaded it, the relative stamps remove the mental math. “2 hours ago” is momentarily unambiguous and it’s immediately clear that it’s more recent than “3 hours ago” 🍬 (1 of 2–4)
Unknown parent

Nate Cull (.social)
Nate Cull (.social)
• •
Suppose someone snapshots their screen, or copy-pastes a "3 hours ago" timestamp into a chat app.

Or suppose you're remoting into their machine, because you're tech support, but you can only view, not send keystrokes, and you're observing that timestamp. Oh, and it's on a webpage which doesn't update automatically but only when the page was last refreshed.

When did that event happen?

Has your life been simplified and made better by relative timestamps?

Mark doesn't like this.

Unknown parent

Nate Cull (.social)
Nate Cull (.social)
• •
Well, if you're doing Zoom or Teams calls with friends or companies not in your country, you'll quickly find that "is the person I'm calling awake right now where they are" is quite a useful piece of information.

Also if you're doing log forensics, or open source intelligence, or just following news stories, "which story / event happened before which other story / event, when the reporters of those events may be on different continents" is also quite important to know.
in reply to Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)

Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)
Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)
• •
🍬 While it’s not immediately obvious whether 20:33+4 is before or after 11:50-5 unless you convert both to UTC to find 16:33 is before 16:50.
All of @natecull’s points are for the admins, auditors, and help desks. Especially for chat services, they may deliberately obscure times with relative time stamps specifically to obstruct OSINT. No one wants to use accountability.chat unless they know they need it. 🍬 (2/2?)
@Nate Cull (.social)
in reply to Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)

Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)
Lyra (🎼, 🦄) & Bon-Bon (🅱️, 🍬)
• •
🍬 For chronological feeds—whether chatlogs or newsfeeds—, ordering is still preserved in both cases and the exact time stamps are only relevant when the precise timing between messages is import or (more frequently) when the messages were sent in relation to external events matters. Algorithmic feeds are where a fast comparison for the end user matters most. 🍬 (3/2+?)
in reply to Nate Cull (.social)

Mark
Mark
•
Really the important thing is to get the compromise method right
⇧