You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi @schultek, thanks for the package! In #125, you explained that: "The default mapper for DateTime transforms it to UTC when encoded, so that there is no problem when the value is passed to some other program in a different local timezone." This is great, because that's how most databases store DateTimes as well.
However, I noticed when deserializing, the resulting DateTime object is still in UTC. You also explained that: "Fyi be aware that you always can make your own mapper for DateTime and use it globally for all DateTime fields, if that helps." OK, so I will do that by copying and modifying DateTimeMapper and using MapperContainer.globals.use(LocalDateTimeMapper()); as the docs suggest.
IMHO, it might be good to do something like this (convert back to local if encoding mode was to UTC):
@overrideDateTimedecode(dynamic value) {
final dateTime =switch(value) {
String value =>DateTime.parse(value),
num value =>DateTime.fromMillisecondsSinceEpoch(value.round()),
_ =>throwMapperException.unexpectedType(value.runtimeType, 'String or num'),
};
returnswitch (encodingMode) {
DateTimeEncoding.iso8601String => dateTime,
DateTimeEncoding.utcIso8601String => dateTime.toLocal(),
DateTimeEncoding.millisSinceEpoc => dateTime,
};
}
I think it might be less surprising to users of this package if this were the default behavior, as I used a date picker in my app, then on refresh (restore from JSON) it was switching to UTC and I realized it was in the mapper. Of course, another DateTimeEncoding value could be added, i.e. DateTimeEncoding.localUtcIso8601String... Maybe/maybe not...
What do you think?
The text was updated successfully, but these errors were encountered:
Hi @schultek, thanks for the package! In #125, you explained that: "The default mapper for DateTime transforms it to UTC when encoded, so that there is no problem when the value is passed to some other program in a different local timezone." This is great, because that's how most databases store DateTimes as well.
However, I noticed when deserializing, the resulting
DateTime
object is still in UTC. You also explained that: "Fyi be aware that you always can make your own mapper for DateTime and use it globally for all DateTime fields, if that helps." OK, so I will do that by copying and modifyingDateTimeMapper
and usingMapperContainer.globals.use(LocalDateTimeMapper());
as the docs suggest.IMHO, it might be good to do something like this (convert back to local if encoding mode was to UTC):
I think it might be less surprising to users of this package if this were the default behavior, as I used a date picker in my app, then on refresh (restore from JSON) it was switching to UTC and I realized it was in the mapper. Of course, another
DateTimeEncoding
value could be added, i.e.DateTimeEncoding.localUtcIso8601String
... Maybe/maybe not...What do you think?
The text was updated successfully, but these errors were encountered: