Prisma1: Add scalar field type `TIME`

[joshhopkins]

What feature are you missing?

The TIME field (values in 'HH:MM:SS') handles use cases where date is of no concern. This is common in scheduling applications.

How could this feature look like in detail? Tradeoffs?

HH:MM:SS (ISO 8601)

[iamclaytonray]

Wouldn't you just grab the time for a createdAt or updatedAt and parse it?

[joshhopkins]

You could, but the use case has no need for a date at all. i.e "do X at 16:00:00 on the first day of the month"

[iamclaytonray]

Just my own opinions here, but I would do something like:

type User @model {
  id: ID! @isUnique
  name: String!
  meetingTime: DateTime!
  # other stuff
}

And then just use moment.js (or lib for whatever language), and parse just the time value. That would prevent more bulk going into a framework that already supports this out of the box. For example, in moment, you can do:

// imports & other code

moment(this.props.meetingTime).format("HH:MM:SS")

[iamclaytonray]

^ Or something like that. I didn't look at the docs and honestly never remember the correct syntax for moment

[joshhopkins]

That works. Could also store the number of minutes past midnight as an integer. There's nothing inherently wrong with those options, we'd just prefer to keep things clean. Currently when calling a mutation and passing time only to a DateTime field type, Graphcool automatically appends 01-01-1970.

[iamclaytonray]

I'm not saying to throw the idea out the window. Just wanted to see if the options on the table were tried. 🙂

[kbrandwijk]

Also, see: https://www.npmjs.com/package/graphql-iso-date for a standard implementation for Date, Time and DateTime.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

[impowski]

Any update on this?

[nealoke]

I feel this type would make the GraphQL datamodel more descriptive and explicit.