Skip to content
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 serializes to UTC by default... good, but then how to deserialize back to local time zone? #206

Open
tgrushka opened this issue Jun 27, 2024 · 3 comments
Labels
enhancement New feature or improvement good first issue Good for newcomers

Comments

@tgrushka
Copy link

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):

  @override
  DateTime decode(dynamic value) {
    final dateTime = switch(value) {
      String value => DateTime.parse(value),
      num value => DateTime.fromMillisecondsSinceEpoch(value.round()),
      _ => throw MapperException.unexpectedType(value.runtimeType, 'String or num'),
    };
    return switch (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?

@schultek
Copy link
Owner

How about adding a DateTimeDecoding value to choose from e.g. "unchanged", "asUtc" and "asLocal".

Then its independent of the encoding, ans also not a breaking change.

@lukepighetti
Copy link

my expectation here is that dart_mappable does not change the timezone of dates that I give it to serialize

@azliR
Copy link

azliR commented Nov 2, 2024

How about adding a DateTimeDecoding value to choose from e.g. "unchanged", "asUtc" and "asLocal".

Then its independent of the encoding, ans also not a breaking change.

yes please, need one here as well

@schultek schultek added enhancement New feature or improvement good first issue Good for newcomers labels Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants