Validation of datetimes

[shuttle1987]

We currently have a BlogPost class that looks like this:

import typing
from datetime import datetime

from gilbert.content import Templated, Content

class BlogPost(Templated, Content):
    title: str
    authors: list
    posted: datetime
    modified: typing.Union[None, datetime]
    category: str
    tags: list
    template: str = "blog/post.html"
    summary: str
    draft: bool

We want to make sure a posted item (the post date) contains a proper datetime. The following contains no posted however it seems to pass through the validation with no issues:

content_type: BlogPost
title: My Third Post!
authors: 
- Alysha
category: software
summary: A short description
---

Hello!

Is there something we are getting wrong in our BlogPost definition here?

[funkybob]

Currently the schema only ensures values you set are correct.

It doesn't ensure values without defaults are provided. It wouldn't take much to convince me that it ought enforce that.

[shuttle1987]

In this particular instance we want to make sure that every one of these items is present with the exception of the modified field that may not be there.

I guess our need is some way to make sure that all fields we wanted to be present are actually there, and we have the notion of an optional field, like the modification date field that may be missing but has to be a DateTime if it's there. If someone supplies a None for the modified time here I suspect this passes validation? If there was a change that introduced that lets you enforce that the values have to be there it would be nice to have some way of marking that the values could be optional. If there's no enforcement then it would be nice to have some optional way of making sure that a field is present and valid.

[funkybob]

So I'm experimenting with adding this, and my tests [oh wow, I have tests, don't I? :) ] show my original intention was that the error would raise if you accessed a no-default attribute without a value.

This is conflicting with the new approach.

From memory, I wanted the schema to act stand-alone, so you could instantiate a schema derivative, and then set its values. I'm not sure of how much utility this still is.