[08/15/2020 @11:37]: Re: Dates in Gemini

Ahh dates. As long as humans have kept time they have had to wrestle with how to represent it. The first time I got a job in IT with equipment in multiple time zones the nightmare began for me.

easeout ran into the classic date problem with CAPCOM and posits a more general standard for Geminispace in general.

CAPCOM

gemini://tilde.team/~easeout/glog/2020-08-15-dates-in-gemini.gmi

Over the years I have settled into the following pattern for dealing with dates and it has worked pretty well across a pretty wide range of projects and scales.

Machine to machine dates are in UTC

Human-facing dates are in the authored time zone.

In the case of the machine-to-machine communication my preferred use of UTC largely follows from my preferred use of UNIX time stamps in the software that I write. It makes comparing time stamps and most other operations easier if you can work in One True time format. You can see this in the various XML feeds that I generate. The dates in them that are generated by the software are in UTC and the dates generated by me are in my local time zone.

Gemlog ATOM feed

Web blog RSS feed

Thoughts RSS feed

For person-to-person communication there are a number of options, as easeout pointed out.

Agree on a universal time zone

Local time

Relative time

UTC vs Local Time

I feel like universal time in this context is lossy. The reality is that there is context preserved in the article dates -- the fact that I'm writing this on a Saturday morning means something. Given my UTC offset it would only be Saturday afternoon if I dated the post in UTC, but in easeout's case his local time and UTC time spanned a day so to the casual observer his post from Friday evening would appear to be from early Saturday night, which could change the context within it was written.

Time is relative

Relative time seems ideal as far as context goes but producing it imposes significant technological challenges. Either the page needs to be rendered by the server every time it is requested or there needs to be a specification (formal or otherwise) for Gemini clients to detect and render dates in received documents. easeout also points out that the asserted date (eg: '30 minutes ago') becomes stale immediately after being retrieved from the server, which further complicates matters.

Conclusion?

So for all of those reasons I think that it makes the most sense that any dates exchanged by machines should be in UTC (or I suppose in a format that explicitly states the time zone) and that dates a person types into a file are whatever makes most sense to the author.

↩ back to index

backlinks [geminispace.info]