-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DateTime deserialization handling #61
Comments
Related stack I'm looking at its
As to when the |
I have also tried public class DateTimeExpressionProvider : ExpressionValueProvider
{
public DateTimeExpressionProvider(MemberInfo memberInfo) : base(memberInfo)
{
}
public new void SetValue(object target, object value)
{
var dv = (DateTime)value;
base.SetValue(target, dv);
}
}
public class SpecialContractResolver : DefaultContractResolver
{
protected override IValueProvider CreateMemberValueProvider(MemberInfo member)
{
if (member.MemberType == MemberTypes.Property)
{
var pi = (PropertyInfo)member;
if (typeof(DateTime).IsAssignableFrom(pi.PropertyType))
{
return new DateTimeExpressionProvider(member);
}
}
return base.CreateMemberValueProvider(member);
}
} But this also never gets called for data provided from BreezeJS, only on serialization of data from BreezeSharp |
DateTime handling can be done via NewtonSoft configuration, and critically making sure EF sets DateTime.Kind, which it doesn't by default. NewtonSoft configuration:
EF configuration. Call the following with the
This should ensure that all inbound and outbound DateTime are correctly handled as UTC. |
Grazi, you're a saint. Hope it's this simple Outbound seems to be fine, it doesn't set Kind but it serializes outbound correctly with no issue (BreezeJS receives the value as UTC) |
With BreezeJS, you have the additional challenge that the browsers always convert dates to local time, so you have to handle that and shift the offset, so that the dates display consistently as UTC. You can do that by overriding the date parsing and serialization in BreezeJS.
Keep in mind, this only works for entitles. If you return projections from the server, then you have to parse/map dates in the JSON as Breeze will just pass them through to the caller as-is. |
The current plan was to leave js Dates as is and normalize them on display, but I'll definitely play around with this to see if it opens up some freedom. |
Okay, so, as observable above, I've been iterating through this and making progress on questions I would have asked, but I'm stumped. We use both DateTime and DateTimeOffset in our system and Offset doesn't seem to be handled. I tried updating the snippet above, which appears to work, but it doesn't seem to make any difference, and I can't seem to make any headway. this.metadataStore.setProperties({
serializerFn: (dp: breeze.DataProperty, val) => {
if (dp.isDataProperty && val) {
console.log(dp.nameOnServer);
console.log(dp.dataType)
if (dp.dataType === breeze.DataType.DateTime
|| dp.dataType === breeze.DataType.DateTimeOffset)
{
console.log(val);
return new Date(val.getTime() - val.getTimezoneOffset() * 60000);
}
}
return val;
},
}); None of these attempts to log output anything, so I cannot seem to interrogate what's going on to make any kind of headway without intervention. 2022-10-27T17:51:58.36+00:00 |
I'm currently trying to use Newtonsoft JSON converters to intercept incoming data to ensure UTC for DateTime, as this gets lost on DB commit.
Currently, I can get
WriteJson
to be called as expected for DateTime, but notReadJson
where I expect to intercept it, so I at least know it's loaded but not sure how to handle this.Trying to figure out if there's a standard way or feature that Breeze conducts serialization that is causing the read to never happen when deserializing objects, or if there's otherwise a way to ensure that the time gets serialized to UTC.
While this can be approached from the front end to try to pre-convert, I'm trying to just handle the problem rather than requiring the client be required to create correctly formatted data (because various frameworks are not doing it and having to figure them all out is just more of what I'm doing here)
The text was updated successfully, but these errors were encountered: