Suggestion: Date & Time-related GDD types

[nytamin]

Background

I have often found myself in situations where I need to provide timestamps to graphics.

We already have the duration-ms GDD-type for relative times.

Suggestions

date

Value represents a date, in YYYY-MM-DD, but not including the time.
GUI is recommended to display the date in a human-readable format, possibly combined with a date picker.

{
  "type": "string",'
  "gddType": "date",
  "gddOptions": {
    "min": string,
    "max": string
  },
  "pattern": "^\d{4}-\d{2}-\d{2}$",  // YYYY-MM-DD
}

(This is designed to align with https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/date)

time

Value represents a time, in HH:mm:ss, but not including the date.
GUI is recommended to display the date in a human-readable format, possibly combined with a time picker.

{
  "type": "string",'
  "gddType": "time",
  "gddOptions": {
    "min": string,
    "max": string
},
  "pattern": "^\d{2}:\d{2}(:\d{2})?$",  // HH:mm:ss or HH:mm
}

(This is designed to align with https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/time)

datetime-local

Value represents a time and date in YYYY-MM-DDTHH:mm:ss
GUI is recommended to display the date in a human-readable format, possibly combined with a date-time picker.

{
  "type": "string",'
  "gddType": "datetime-local",
  "gddOptions": {
    "min": string,
    "max": string
  },
  "pattern": "^\d{2}:\d{2}(:\d{2})?$",  // HH:mm:ss or HH:mm
}

(This is designed to align with https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/datetime-local)

datetime

The value is a simplified ISO 8601 format, see: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString .
GUI is recommended to display the time in a human-readable format, possibly combined with a date-time picker.

{
  "type": "string",
  "gddType": "datetime",
  "gddOptions": {}
   "pattern": "^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z$",  // YYYY-MM-DDTHH:mm:ss.xxxZ  (in UTC)) 
}

[didikunz]

...the example in datetime-local is maybe wrong...

[nytamin]

...the example in datetime-local is maybe wrong...

Ah thanks :) updated now

[didikunz]

A very use full addition. We should add that anyway.

[didikunz]

Another thought: In most cases it is more common to use the local date and time and not the UTC. So maybe it would make sense to have a "datetime" type and a "datatimeUTC", respectively "time" and "timeUTC", where the "standard" type is local-time.

Maybe we could also add a setting to send the data as a number (Unix time) for templates, that need to do calculations.

[nytamin]

local date vs UTC

I'd recommend to go for

• date: in local time
• time: in local time
• datetime-local: in local time
• datetime: always in UTC (maye rename it to datetime-utc?)

maybe it would make sense to have a "datetime" type and a "datatimeUTC"

It is also possible to have GDD-types with different data types (eg: select), so we could do something like this:

// datetime with string value (in ISO 8601 format)
{
  "type": "string",
  "gddType": "datetime",
  "gddOptions": {}
   "pattern": "^\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z$",  // YYYY-MM-DDTHH:mm:ss.xxxZ  (in UTC)) 
}
// datetime with unix-timestamp (in milliseconds)
{
  "type": "number",
  "gddType": "datetime",
  "gddOptions": {}
}

[didikunz]

It is also possible to have GDD-types with different data types (eg: select)

I like the idea, but it does not solve the local time vs UTC problem for unix timestamps, as the integer type lacks the pattern property. But maybe that can be left to be solved with a description text, that prompts for either one. This would leves us with only a dattime GDD type, without split it up further. If handled as string (what makes sense in most use cases) the pattern property leaves enough possibilities to shape the data entry, leaving the unix-timestamp for special cases.

[jhobz]

To document part of the discussion during the March 18th call, I think adopting the RFC 9557 standard for gddType: 'datetime', specifically the optional inclusion of a time zone, would allow us to eliminate gddType: 'datetime-local' at minimum. I think there are arguments to be made on whether there should just be a single "datetime" type and the graphic can ignore half of the data if it is not needed (either the date portion or the time portion), or if it should remain split into three types for the different portions, but I think either approach would be satisfactory.

[didikunz]

I am a lazy typer, so I would want to have a way to restrict my users to only the amount of data, that is needed. So we should anyway have some kind of pattern property, regardless how we interprete the data internally.