Time zone problem (Android)

Hi there
I have a problem with the automatic correction the value of DateTime variable if latter is sent by WCF.
My Android device time zone is set to -1 comparatively to the WCF server side and when request reaches the server, I see the date, say, 11/9/2017 12:00 AM is corrected to 11/8/2017 11:00 PM.
The bad thing is that my DATE changes (I do not care about the time part of it).
It looks like the correction happens on the serialization step.
Is there any way to stop this auto correction?
Thanks.

Tagged:

Posts

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    I'm missing the problem. If its a difference of -1 hour... and the adjustment is from 09nov at 0000hrs to 08nov at 2300hrs... That's a correct adjustment.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭
    edited November 7

    @NickRenzhiglov - If your server is working with UTC, just make sure that your client code either works with UTC (DateTime.UtcNow) or converts to/from UTC before sending/receiving datetimes to/from the server.

    If your server is not working with UTC, it probably should be.

  • NickRenzhiglovNickRenzhiglov CAMember ✭✭

    JohnHardman
    It means that I have to convert the DateTime properties for each and every DTO? This is crazy.
    Say, I have item.ThisDate of DateTime. It is bound to the GUI control. So before sending it to a server something like SpecifyKind(item.ThisDate , DateTimeKind.UTC) must be done? This is crazy. Tones of places!

    BTW, this problem manifests only for mobile client. The Silverlight client works smoothly, no automatic date conversion.
    Maybe, it is somewhere in WCF ClientConfig?
    Thanks.

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭
    edited November 7

    @NickRenzhiglov - Not crazy at all - it's standard practice for any client/server-based systems that work across (or may work across in future) time zones.

    Alternatively, if your client and server maintain a connection and the protocol agreed between them is that the time zone of the client is specified early in the client/server interaction, the server could do any conversions for the client. That's not the usual way of doing things though.

    Remember too, that daylight-savings will need to be taken into account too.

  • NickRenzhiglovNickRenzhiglov CAMember ✭✭

    protocol agreed between them is ...

    Any clue on how to disrupt that agreement?

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @NickRenzhiglov - I'd ask whoever wrote the server-side code that your app is communicating with. My guess is that if the server is using UTC, they will bounce it back to you to do code changes client-side.

  • NickRenzhiglovNickRenzhiglov CAMember ✭✭

    "They" is me. I write both sides and I have no idea why Silverlight client works in one way, but the mobile works differently.
    Anyway, thanks for your reply. It shows that the problem is tricky :-(

  • JohnHardmanJohnHardman GBUniversity ✭✭✭✭✭

    @NickRenzhiglov - Any interaction between two computers requires an agreed protocol. That protocol includes what time zone is used for dates and times, and how daylight savings is handled. The typical answer is that UTC is used for communicating dates and times, and that the client does any necessary conversion required for the UI. That means that the client needs helper functions for doing conversions. If using MVVM, it is likely that your data model will use UTC, and the ViewModel will do the necessary conversions, making use of the helper functions. Methodical and tedious, but not IMHO tricky.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @JohnHardman Is exactly right on this. Describes how every client/server situation I've been a part of operates.

Sign In or Register to comment.