DST(DaylightSavingTime) issue for DateTime.Now

TEklundTEklund USUniversity ✭✭

We are having problem with DST for DateTime.Now on android where the time in the app is 1 hour behind the time of the phone. This is causing major issues for fraud detection, syncing and display of currently relevant data.

The timezone affected right now seems to be GMT +2:00, CEST.

The problem was discovered sep 26 running latest stable version of xamarin.

Posts

  • GerardMaternaGerardMaterna BEMember
    edited September 2014

    Same for me this morning.

    DST change for GMT+2, CEST is 26 october. Is it possible that there is a bug that makes this changes on 26 september instead?

  • I found this post :
    http://forums.xamarin.com/discussion/12142/convert-time-to-nz-zone-is-wrong-daylight-savings-issue-help

    I could get a correct local datetime in zone GMT+2 by using NodaTime (https://code.google.com/p/noda-time/) and this code:

        var timeZone = DateTimeZoneProviders.Tzdb ["Europe/Brussels"];
        var zonedDateTime = Instant.FromDateTimeUtc (DateTime.UtcNow).InZone(timeZone);
        DateTime localDT = zonedDateTime.ToDateTimeUnspecified ();
    
  • SebastianSeidel.9226SebastianSeidel.9226 DEInsider, University ✭✭✭✭

    It looks like this is a bug in Xamarin. I ran into it last friday and could fix it with this bug-ticket. It contains a workaround too.

    https://bugzilla.xamarin.com/show_bug.cgi?id=4227

  • TEklundTEklund USUniversity ✭✭
    edited September 2014

    I have tested setting my date to different dates and it seem like there is a bug that change DST worng month for GMT+2.

    Sep 25 is ok,
    Sep 26 1 hour behind,
    Oct 25 1 hour behind,
    Oct 26 is ok

  • I have had suprises like that when I converted datetime from 0-index based month (0-11) to 1-index based month (1-12). If it is the same here, it is possible that the other date (from winter datetime to summer datetime) is impacted too (I have not checked)

  • Workaround code for me with both Nodatime and System implementations:

    //#define USE_NODATIME
    
    using System;
    #if USE_NODATIME
    using NodaTime;
    #endif
    
    namespace TimeZoneHelper
    {
        public static class TimeZoneHelper
        {
            public static DateTime DateTimeNow()
            {
                return DateTimeLocal(DateTime.UtcNow);
            }
    
            #if USE_NODATIME
            private static DateTimeZone localTimeZone = null;
            #endif
    
            public static DateTime DateTimeLocal(DateTime Utc)
            {
                try
                {
                #if USE_NODATIME
                    if(localTimeZone == null)
                    {
                        try
                        {
                            localTimeZone = DateTimeZoneProviders.Tzdb[Java.Util.TimeZone.Default.ID];
                        }
                        catch
                        {
                            localTimeZone = DateTimeZone.Utc;
                        }
                    }
                    return Instant.FromDateTimeUtc(Utc).InZone(localTimeZone).ToDateTimeUnspecified();
                #else
                    return TimeZoneInfo.ConvertTime(Utc, TimeZoneInfo.Utc,
                        TimeZoneInfo.FindSystemTimeZoneById(TimeZoneInfo.Local.Id));
                #endif
                }
                catch
                {
                    return Utc;
                }
            }
        }
    }
    
  • This is quite inconvenient, especially because it not only affects DateTime.Now, but any DateTime values that are transferred to the device from external sources. E.g. send an XML file with a datetime to the device, and it arrives with 1 hour reduced because of the timezone difference.

    By the way, the Java classes seem to work correctly, so it may be a solution for some people to use
    new Java.Util.Date()
    instead of
    DateTime.Now

  • TEklundTEklund USUniversity ✭✭

    I just got this response from the support

    I'm sorry to hear that you're still having difficulties with DateTime.

    I've gone ahead and included the download link for the previous stable build, which I believe doesn't exhibit this particular bug.

    Mac: http://download.xamarin.com/MonoforAndroid/Mac/mono-android-4.14.0-55.pkg

    Windows: http://download.xamarin.com/XamarinforVisualStudio/Windows/Xamarin.VisualStudio_Setup-3.3.47.msi

    As for when the issue will be resolved, I will need to discuss this with our Xamarin.Android engineers which are mostly based on the east coast of the US. Once I've heard from them, I shall be in touch.

    Downgrading solved the issue for the time being but it's not the solution.

  • StephanNielsenStephanNielsen DEMember ✭✭

    Downgrading solved the issue here as well for now. Besides DateTime.Now also function like DateTime.ToLocal() return wrong values.

  • KeyzerSKeyzerS NOMember ✭✭
    edited October 2014

    Aha! Thank you so much for this thread. I have been going crazy trying to understand what was going on with my app. Suddenly all times were off.

    I do not use Visual Studio, so im gonna mail them to get the correct version to use. Downgrading kind of seems like a messed up solution for this, but OK.

  • DanielPDanielP USMember

    Hopefully they will fix that very soon because it's a true showstopper. I can't release my app if DateTime.Now doesn't match the date/time of the device...

    I think this is the relevant bug in bugzilla:

    https://bugzilla.xamarin.com/show_bug.cgi?id=23405

  • constructorconstructor GBMember

    Has anyone links to Windows versions of Xamarin.Android and Studio that do not have this bug (or a resolution)?

    I can not and will not deploy an app that has broken DateTime values. This is really setting me back.

  • john82john82 ITMember ✭✭

    I've just installed the Xamarin 3.7.203 on my visual studio develop machine. The issue is still there, the DateTime is still wrong :(

  • BobColemanBobColeman NZMember

    Agree with Francesco, the date bug is still there in 3.7.203.

  • constructorconstructor GBMember

    Anyone know of Windows Xamarin.Android and Xamarin Studio versions (with download links) that I can build against today that do not have this bug?

    I can not deploy on store!

  • StephanNielsenStephanNielsen DEMember ✭✭

    working versions are posted above. according to bugzilla the bug is fixed but it is unknown when it will be in any of the released versions.

  • I hope they fix this issue ASAP! It's frustrating having my working App be ripped of all of the sudden!

  • BazookasMobilestudioBazookasMobilestudio BEUniversity ✭✭

    A Fix would be very much appreciated here as well, also publishing with the older build but this is not a longterm solution.

  • TEklundTEklund USUniversity ✭✭

    Just received an update, but the problem still exist.

    3.7.203

    >

    Addresses an issue evaluating DateTime in some timezones

    Did this update solve anything for you?

  • PaulDistonPaulDiston USUniversity ✭✭✭✭

    This update doesn't seem to solve the problem.

  • BobColemanBobColeman NZMember

    We have to get a release out soon, so for now I've coded the following fix and called it everywhere we used DateTime.Now

    public static DateTime Fixed(this DateTime Value)
            {
                var FixedDate = TimeZoneInfo.ConvertTime(Value.ToUniversalTime(), TimeZoneInfo.Utc, TimeZoneInfo.FindSystemTimeZoneById(TimeZoneInfo.Local.Id));
                return FixedDate;
            }
    

    Usage: var CorrectedDate = DateTime.Now.Fixed();

  • ianmercerianmercer USMember ✭✭

    This bug is insidious. In addition to affecting DateTime.Now, it also affects DateTime.LocalDateTime and DateTime.Parse. Working around it using Noda time has been very hard in the heavily time-dependent code I'm working on. Running side by side the same app code (Xamarin Forms) was displaying different values on iOS and Android.

    Hope this can be fixed soon!

  • constructorconstructor GBMember
    edited October 2014

    Has ANYONE from Xamarin made comment on this? Is there a previous version that we can download to deploy to the store today?

    EDIT: Links to downloads posted here:

    http://forums.xamarin.com/discussion/comment/81432#Comment_81432

  • TedRogersTedRogers USMember ✭✭✭✭

    @BobColeman‌ The above extension you provided works great for going UTC to local but I couldn't figure out how to do the reverse and get the right result. Any ideas?

  • OlafBarteltOlafBartelt DEMember ✭✭

    WTF? This has to have a simple reason which any good developer should be able to fix in an instant, even more so given the fact that a previous version did not have the same problems. Just check out the changes you did and you should have the solution...

    I'm using ServiceStack for our client/server code and ServiceStack.Text uses ToLocalTime() as well, but I have no interest (and time) to modify their code. This is basic functionality that should just work (unlike the totally instable connection from Visual Studio on a Windows machine to the iOS Build Host on a Mac or other, almost show-stopping bugs, that Xamarin doesn't seem to be able to fix :-().

    I'm really waiting for a statement on when this will be fixed. Telling people to downgrade isn't the way to go, upgrading to a fixed version and never having such basic bugs in stable releases in the future again should be.

  • CraigSchulteCraigSchulte USMember

    Needs to be fixed ASAP. Downgrading is not a good option with Lolipop being released soon. I want to have all the latest patches available in order to better support Lolipop.

  • constructorconstructor GBMember

    Has anyone heard/read any comment on this from Xamarin? Thanks.

  • OlafBarteltOlafBartelt DEMember ✭✭

    After upgrading today to the newest available version (though I'm pretty sure I do this every other day), this issue seems to be fixed for me. Hope this is really due to the update and not to the date today being different than yesterday ;-)

    And sorry for the rant in my previous post, but, as you're probably aware of, things like these (breaking basic functionality) should just not happen. Keep up the good work, and (though off topic) get that goddamn connection to the iOS Build Host fixed/stable ;-) Please! It's a pain in the a*s to have your app debug session interrupted in 1 out of 3 sessions on average and to have to start it two times each time you abort the app and make changes to your code (because the emulator just doesn't seem to kill your app).

  • TedRogersTedRogers USMember ✭✭✭✭

    @OlafBartelt‌ - did you update to the last stable version? Because, I did update to that and I still see the problem.

  • Hi all, note that on the 26 october, for DateTime.Now, the problem will disappear by itself because GMT+2 will indeed change by 1 hour. It will not mean that it is fixed, it will stay hidden until next year. Hopefully, it should be fixed by then.

  • OlafBarteltOlafBartelt DEMember ✭✭

    @TedRogers: yeah, I updated to the latest stable version (I only use stable versions if possible) and the problem disappeared for me, though I haven't tested setting the date back to 10/16/2014 for example, since it wasn't working on the 16th, but worked on the 17th with the new version.

    But maybe we're doing something different. I had the problem with DTOs transferred by ServiceStack from my Windows service to my Android client. Dates from the server always were 1 hour off, the other way it was correct. This involves the usage of DateTime.ToLocalTime() on the client, since the dates are transferred in UTC in the JSON. So I'm not using DateTime.Now or noticed problems with it, but DateTime.ToLocalTime...

    I'll test it again shortly and keep an eye on DateTime.Now as well and post my results...

  • OlafBarteltOlafBartelt DEMember ✭✭

    Update on my last post: everything is working as it should for me (DateTime.Now and DateTime.ToLocalDate). Both server and devices GMT+1 daylight saving time. Xamarin Android 4.18.0.38, Xamarin 3.7.226.0, Visual Studio 2012 on Windows, Android 4.4 on a Motorola Moto G.

  • TedRogersTedRogers USMember ✭✭✭✭

    I am taking a UTC time and converting it to a local time using DateTime.ToLocalTime() and that is still not working correctly with the latest stable build on Android.

  • OlafBarteltOlafBartelt DEMember ✭✭

    :-( Great, that means that I'm just lucky (probably in my combination of device, OS version, locale, whatever), which is kind of frightening. Any news, Xamarin?

  • OlafBarteltOlafBartelt DEMember ✭✭

    Is anybody reading this forum at all or is there a better way to submit bugs?

  • huhuhujujujuhuhuhujujuju HRMember

    I have this issue too.. time zone gmt +2
    I'm seeing an hour early with DateTime.Now

  • DavidSchulteDavidSchulte USMember

    This is affecting other timezones as well (GMT - 5).

  • ArthurAquinoArthurAquino BRMember

    Also seems to be affecting GMT-3...

  • StephanNielsenStephanNielsen DEMember ✭✭

    bugzilla says (again) that the issue is resolved/fixed. doesn't say anything when it will be released though...
    https://bugzilla.xamarin.com/show_bug.cgi?id=23405

Sign In or Register to comment.