Re: human language oriented datetime standard

The problem I am tryibg to solve is that there is no handle how to interprete a value as text. If offer a calander of events on a webpage, and I wish to phrase the dates as "tomorrow 9pm" or "may 15th 17:00" there is no certainty that an indexer will understand the format.
An alternative would be to also include a proptery as metadata with an iso-8606 format of that same datetime.
But ideally we would not like to add duplicate data, and would like to mark up visable information rather than adding meta elements.

What ai am proposing to do is maje a start with a less formal standard, but a standerd never the less, to in the future provide an alternative where one can mark up a date in a less formal context and know that indexers or others making use of the data will have a handle on it though this standard.

Niels

On June 30, 2018 7:28:52 PM GMT+02:00, Thad Guidry <thadguidry@gmail.com> wrote:
>Sorry, but...what problem are you trying to solve ?
>
>The reason for ISO 8606 standards in the first place...to improve
>interoperability and avoid confusion between a human and a human, or a
>machine and a human, or all.
>
>Schema.org already supports simple TEXT on any property, regardless if
>it
>is stated or not, and does not prevent you from expressing as much or
>as
>little as you like about a Date.
>
>Your scenario seems like those of others before you, where you could
>have
>your server code or javascript take a DATE from your database or
>backend
>system and just convert that to a TEXT type and populate it.
>
>Schema.org allows you to say, if you want:
>
>"doorTime": "tomorrow"
>
>instead of
>
>"doorTime": "2018-06-30T15:38:51Z"
>
>You are also not prevented from providing BOTH forms, when and where
>you
>need to provide Machines and Humans what they need for understanding.
>
>The reason to use a Machine Readable standard rather than Human
>Readable
>no-standard, is to improve understanding by the rest of the world who
>could
>know exactly when your "tomorrow" is.
>
>-Thad

Received on Saturday, 30 June 2018 17:43:44 UTC