Ben Langhinrichs

Photograph of Ben Langhinrichs

E-mail address - Ben Langhinrichs







Recent posts

Mon 15 Mar 2021

When moving from X to Y, you must know about both X and Y



Wed 3 Mar 2021

From NSF to Oh Shiny!



Mon 1 Mar 2021

Eighteen years of blogging


April, 2021
SMTWTFS
    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

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?
 
"@created""2021-02-22T16:32:19Z"
 
"@created""2021-02-22T11:32:19.53-05:00"
 
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:

No documents found

Have your say:

Name *:
E-mail:
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...