gemini.git

b02dbc5b1622fef179ebea97d405548f3bd85d44 - Matthew Ernisse - 1597505906
new post
diff --git a/users/mernisse/articles/09.gmi b/users/mernisse/articles/09.gmi
new file mode 100644
index 0000000..ae3b7fb
--- /dev/null
+++ b/users/mernisse/articles/09.gmi
@@ -0,0 +1,66 @@
+---
+Title: Re: Dates in Gemini
+Date: 08/15/2020 11:37
+In-Reply-To: gemini://tilde.team/~easeout/glog/2020-08-15-dates-in-gemini.gmi
+
+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.
+
+=> gemini://gemini.circumlunar.space/capcom/	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.
+
+=> /~mernisse/atom.xml	Gemlog ATOM feed
+=> https://www.going-flying.com/blog/feed.xml	Web blog RSS feed
+=> https://vociferate.azurewebsites.net/api/rss	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.