Is it possible to define time at different resolutions in SHACL shapes targeted to subClasses?

I am facing a problem regarding the ability to enforce different resolutions of expressing time for different rdfs:Classes. I have a graph where:

:event a rdfs:Class.
:subevent rdfs:subClassOf :event.

and also related SHACL-rules where the event class requires its temporal existence reported only at the resolution of date, whereas the subevent is a more precisely defined point in time:

:eventSH a sh:NodeShape;
   sh:targetClass :event;
   sh:property [
      sh:path :happeningOn;
      sh:datatype xsd:date;
      sh:minCount 1;
      sh:maxCount 1;
   ].
:subeventSH a sh:NodeShape;
   sh:targetClass :subevent;
   sh:property [
      sh:path :happeningOn;
      sh:datatype xsd:dateTime;
      sh:minCount 1;
      sh:maxCount 1;
   ].

So, in an ontological sense, I have the need to express events at a varying resolution (some events are only known to occur on a certain year, some e.g. on a certain date, and some events are known to happen on a precise point in time).

In essence, the question is: is SHACL capable of expressing a constraint where the subevent timepoint must fall inside the superclass date? Is the only possibility to use SHACL-SPARQL for this? I understand that by nature year, month, day, date are different beasts compared to dateTime, as they are not points but rather ranges between two points in time.

I can't seem to find a function to convert dateTime to date, perhaps just casting into xsd:date would do it but not sure whether this is something most engines support in an unified way. So my primary question is - is this requirement of different resolutions for the same inherited predicate achievable in pure SHACL itself? Or should I resort to using different predicates with the help of e.g. OWL Time ontology? This would seem like an unnecessary complication compared to just using pure SHACL.

edit: As a clarification, I do recognize that in its current shape there is no possibility to define a subevent, as the shapes that restrict it are contradictory.

For this scenario you cannot use sh:datatype. Subclasses can only narrow down the constraints from superclasses. So if the superclass allows xsd:date then the subclass cannot constraint it further to xsd:dateTime. While it may sound intuitive to expect dateTimes to be a "subset" of dates, this is not how SHACL works, because it will compare the exact datatypes only, i.e. the URI of the datatype must match.

I also believe it would be very unusual to have a property that is either xsd:date or xsd:dateTime, depending on context. This makes it harder for applications to process. For example imagine an algorithm that is working against event and doesn't know about sub-event. Such an algorithm would be best if it could always assume xsd:date literals. One design alternative would be to define two properties, where the xsd:date property is always present (even for instances of the subclass), while the subclass may have another property to represent more details.

BTW to convert from xsd:dateTime to xsd:date, you can use xsd:date as a SPARQL function: BIND (xsd:date(NOW()) AS ?date)