Replies: 3 comments 2 replies
-
Good question. I have just came to create similar question and saw this. Did you make simple test? based on my test with UWP, it is the case as you described but i need to check with Android and Ios also. |
Beta Was this translation helpful? Give feedback.
-
Actually this is really not optimal implementation I believe. why would akavache should change the datetime? it should just take convert to tick as it is. If user wants to save it as UTC, it should be the responsibility of the App, not Akavache. Now i have a conflict. there are some I want to save as UTC, some as Local but Akavache restrict me as all or nothing. Of course here we can always save as Local as it will not change the anything but Akavache default is UTC. That should be changed to local not UTC. because for the new users, this is important thing and if someone doesnt pay attention will get wrong implementation and once the data is saved, it is hard to change. |
Beta Was this translation helpful? Give feedback.
-
I understand this, went through the code already but does it not make sense that Local should be default. Because I handle on the app if my datetime is Local or UTC should be and Package shouldnt handle UTC for me. So basically if my Local datetime is |
Beta Was this translation helpful? Give feedback.
-
What is difference between BlobCache.ForcedDateTimeKind and BlobCache.UserAccount.ForcedDateTimeKind?
If I set BlobCache.ForcedDateTimeKind it does not affect BlobCache.UserAccount.ForcedDateTimeKind
Should BlobCache.ForcedDateTimeKind force the DateTimeKind on all locations (i.e. LocalMachine, UserAccount, Secure and InMemory)
Using Akavache 7.2.1 on Xamarin.Android
Beta Was this translation helpful? Give feedback.
All reactions