Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs

Recent posts

Thu 10 Jun 2021

Notes 12 without all the blue

Wed 5 May 2021

Pull public data into Notes on the fly

Thu 29 Apr 2021

Archive a Notes DB off-line w/ Field data and active content

August, 2021
01 02 03 04 05 06 07
08 09 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31

Search the weblog

Genii Weblog

Preservation of all the tiny details

Thu 18 Mar 2021, 11:55 AM

by Ben Langhinrichs
Inline JPEG image
There are a lot of ways to write out an exact date and time, but for the sake of international standards, dates in JSON and other interchange formats should be written using ISO 8601. But even that gives us options. The following two dates represent the exact same moment in time, but do they represent the exact same information?
While they are considered equivalent, are they? What is the piece of metadata that is lost in the first but not the second? It is the original time zone in which the document was created.
Now, this may seem unimportant. In most cases, it probably is unimportant. But if there is one thing I have learned in my years converting data from one format to another, and especially in doing roundtripping or synching of data that must coexist in two different platforms, it is that every detail is precious some of the time or to some of the people. In meeting invites, we see both when the invitation is and what time zone it was created it. If we convert to the first of these two formats and then back, we lose that information, or even if we just pull it out for display elsewhere, we won't have it.
Now, I want to be clear that even the second format is risky. A standard JSON parser that recognize dates may turn these both into the same timedate object. But a savvy parser in a system that has the capability to store time zones will store that time zone with the second format. It can't with the first. The detail is simply lost.
Addendum: Just a quick follow up to this. In reality, you can't determine the time zone itself from the time offset, but you can calculate the local time in which the time was created. Therefore, we offer an option to use an extended construct for Notes time date item values that gives the time zone as a separate value along with the time and date, e.g., "StartTime": {"zone":"EST", "value":"2021-03-01T10:30:00.00-05:00"}

Copyright 2021 Genii Software Ltd.

What has been said:

1126.1. Lagwert
(2021-04-18 11:35)

Thank you for this blog.

Have your say:

Name *:
e-mail addresses will not be displayed on this site
Comment *:

<HTML is not allowed>
Linking: Add links as {{http://xxx|title}}, and they will be activated once approved
Blocked? Unable to post a comment? Please read this for a possible explanation...