Preferences needs overloads for DateTime

[jonathanpeppers]

Description

I ported usage of Xam.Plugin.Settings to Xamarin.Essentials.Preferences in the Evolve 2016 app.

For the most part, the new Preferences class is exactly backwards compatible when loading existing data stored (good job!).

However, we are missing an overload for DateTime, for example I had to do:

public DateTime LastFavoriteTime
{
    get { return new DateTime(Preferences.Get(LastFavoriteTimeKey, DateTime.UtcNow.Ticks)); }
    set { Preferences.Set(LastFavoriteTimeKey, value.Ticks); }
}

It might not be clear for a developer to use a long, I first attempted string and got the following on Android:

Java.Lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String

It might also be worth writing some tests that change the data types and see what the current behavior is?

Steps to Reproduce

1. Port an app from using Xam.Plugin.Settings to Xamarin.Essentials.Preferences, with existing saved settings
2. Try to Get/Set DateTime values

Expected Behavior

There should be an overload for DateTime.

Actual Behavior

Code to convert to/from a long is required.

Basic Information

• Version with issue: 0.0.1.79-preview

Reproduction Link

Commit here.

[jamesmontemagno]

To do: add to wiki.

[jamesmontemagno]

See: https://github.com/xamarin/Essentials/wiki/FAQ-%7C-Preferences

[prashantvc]

Are we going to provide the overload to save/retrieve DateTime from Preference?
It's just too many key strokes to save or read date times :)

[jonathanpeppers]

@jamesmontemagno I agree with @prashantvc.

If the native APIs don't support DateTime, we should have an overload for DateTime that stores them as a long so users don't have to figure it out themselves (or read docs).

[mattleibow]

@jonathanpeppers I think the reason we didn't include this is that we don't have a reliable way to store dates with timezone information and possibly other aspects - what if the timezone of the device changes?

[jonathanpeppers]

@mattleibow I agree that it might be somewhat tricky to get this right--even more reason Xamarin.Essentials should do it instead of putting that work on the developer.

I think you can use UtcTicks: https://msdn.microsoft.com/en-us/library/system.datetimeoffset.utcticks(v=vs.110).aspx

My example above should also be using UtcTicks, but it was already using DateTime.UtcNow.

[Redth]

We can store ticks but that doesn't retain the timezone information about the original date. This may or may not be a problem for some developers.

[mattleibow]

Yeah... We could also create our own save format... $"{date.Ticks};{date.TimeZone}" Who says we have to save only the ticks?

[jonathanpeppers]

I googled around a bit and found this: https://msdn.microsoft.com/en-us/library/system.datetime.tobinary(v=vs.110).aspx

It's not going to encode the timezone, but will retain if it is a local or utc time.

So using ToBinary/FromBinary would:

• Give developers the option to store a local DateTime. IMHO a bad idea, but it will work mostly unless the timezone on the device changes. I honestly don't know a use case you would absolutely have to store a local time.
• Developers that do it the "right way" would store utc DateTime and call ToLocal() if they need to display the time on a UI.