-- Leo's gemini proxy
-- Connecting to tilde.team:1965...
-- Sending request
-- Meta line: 20 text/gemini; lang=en
15 August 2020
It's summertime, so I live in UTC-4. In this glog I've dated my posts in UTC-4, formatted them for display in UTC-4, and generated the atom feed's timestamps in UTC-4. But my post from yesterday evening, the 13th to me, was displayed on CAPCOM in a section for the 14th.
A tale as old as time zones.
It seems likely that CAPCOM is using UTC, which is sensible. But it's not a great experience for readers to follow a link labeled with the 14th and then see a post that declares it's from the 13th.
The web has a few interesting answers for this problem. Live web servers or browser-side code can format dates in the reader's time zone, which yields a familiar and consistent experience from site to site. But here in textworld, we like simple data, not client-side scripts, so formatting after download is not an option. Sending the server a time zone to format with would also be too involved.
Another strategy, which Gemini would support, is for a live server to format a date as an elapsed time, like "30 minutes ago." That's more suitable when the degree of recency is what you want to know. As a tradeoff, it means you can't easily tell exactly when something happened. It's also only correct right when you download the page. Elapsed times go stale.
What I am trying now is to publish this glog's dates in UTC, and pretend as if UTC is a Geminispace standard. My clock says it's the evening of the 14th, but UTC says it's the morning of the 15th, so this post is labeled the 15th. Readers might not all live in the same time zone, but maybe we can keep dates and times consistent for them across sites.
Update: Rather than re-dating my past posts to match UTC, I gave them all times that would make the UTC date agree with UTC-4, corresponding to 7 PM my time. When CAPCOM updated, that fixed the problem I mentioned at the top of the post.
-- Response ended
-- Page fetched on Thu Oct 28 05:18:49 2021