Date type is missing from primitive types

[fictitious]

Not sure if it fits within big picture here, but Date javascript type could well be considered primitive.

[sinclairzx81]

Hi,

Yes, I originally included Date as a type but had decided to remove it from the library. The reason is that Date is not a JSON primitive (JSON only supports strings, numbers, booleans, objects and arrays). For the case of Date, it is typically expressed as a iso8601 string value, sometimes as a unix timestamp (number) sometimes UTC, sometimes even "/Date(1234567)/". So there is verbosity there, but the key point is that the Date type is expressed by way of some "other" more primitive type in JSON, and because of this, the Date type was omitted.

Also, typebox is only really concerned with structural validation, not data validation. If you imagine this as a pipeline, it might look something like..json post > structural validation > data validation > handler where data validation would include checking a string value as being a iso8601 date string, a email address or a zip code. typebox is only concerned that the string exists, but doesn't care so much about what the string contains. This is inline with typescripts structural typesystem which doesn't type check on data, only structure.

However, I would like to have some ability to generate xsd:dateTime from the library, so its something I might consider again at some point. But for now, I am keen to limit types to only types supported in JSON for compatibility.

Cheers !
S

[fictitious]

Well then I suppose there should be yet another logical stage in the pipeline: structural validation > data conversion > data validation, because validation is not supposed to change data type. At the implementation level, ideally all should be done within single pass that traverses the data structure. Also, I would like to keep the definitions for all stages in a single place, without need to repeat data structure description for each stage. So for the time being, I will stick with my own library then. Cheers!

[sinclairzx81]

Yup, implicit conversion should be handled in additional (external) stages where its more clear whats going on.

Btw, also take a look at https://github.com/pelotom/runtypes. Seems there are a few libraries of this sort springing up nowadays. One day, I do hope we get opt-in boundary run time type checking of this sort implemented in the TypeScript compiler itself. If its at all possible to have typescript tie itself to JSONSchema in the same way as .NET / C# types have analogous tooling for XML/XSD, that would be something.

Would be good to organize and formalize a proposal for this sort of thing. Open to collaboration if you are interested.

[ghost]

We use notepack for encoding which supports Date objects.

Would it be possible to re introduce the Date type? We could add this type internally within our project but the problem is that we cannot extend TSchema.

https://github.com/toby-wollit/typebox/commit/9b1171868f7ed48d2ac26f895ce050e112ddc1c5

[hugoattal]

I use Typebox for typing all my routes, and use Fastify framework with implicitly convert dates to string.
I wanted to be able to return a result from my MongoDB straight away, but had conflict with dates type.

I ended writing this custom type:

export const DateKind = Symbol("DateKind");
export interface TDate extends TSchema { type: "string" ; $static: Date; kind: typeof DateKind }
export const TypeDate = Type.String({ format: "date-time" }) as TString | TDate;

It may not be the perfect solution (and it's kinda cheating), but that may help some of you that have the same problem as me. Also, if you have a better solution, don't hesitate to share and tag me!

[derekzyl]

Hi,

Yes, I originally included Date as a type but had decided to remove it from the library. The reason is that Date is not a JSON primitive (JSON only supports strings, numbers, booleans, objects and arrays). For the case of Date, it is typically expressed as a iso8601 string value, sometimes as a unix timestamp (number) sometimes UTC, sometimes even "/Date(1234567)/". So there is verbosity there, but the key point is that the Date type is expressed by way of some "other" more primitive type in JSON, and because of this, the Date type was omitted.

Also, typebox is only really concerned with structural validation, not data validation. If you imagine this as a pipeline, it might look something like..json post > structural validation > data validation > handler where data validation would include checking a string value as being a iso8601 date string, a email address or a zip code. typebox is only concerned that the string exists, but doesn't care so much about what the string contains. This is inline with typescripts structural typesystem which doesn't type check on data, only structure.

However, I would like to have some ability to generate xsd:dateTime from the library, so its something I might consider again at some point. But for now, I am keen to limit types to only types supported in JSON for compatibility.

Cheers ! S

hi its 2022 have you considered date object