Are DateTimeOffset concepts supported?

#1

We have used DateTime concepts in our application for some time now. Recently, we have moved on to using DateTimeOffsets to avoid messing with time zones, daylight saving, and the like. For the most part, DateTimeOffsets are fine on their own and don’t need to be wrapped into a Concept. But there are some DateTimes we feel are important in the domain and should be modelled as concepts.

So, if we want to get rid of DateTime, do we also have to get rid of DateTime concepts?
If we try replacing ConceptAs with ConceptAs we get the following exception when sending in a command:

image
image.png1790×209 49.3 KB

2 Likes
#2

I’m guessing you have are using a concept in your command that wraps DateTimeOffset and are sending in a DateTime. If that is so, or the converse, you could make an implicit cast from one concept to the other in the concept definition. In that cast you can get the DateTime from the DateTimeOffset in whatever time zone you are using and return the concept wrapping that.

I highly recommend using UTC everywhere you’re storing and using DateTimes. Otherwise you have to be really careful to always store the time zone with the DateTime.

1 Like