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.