Bug 23405 - DateTime.Now returns time off by 1 hour
Summary: DateTime.Now returns time off by 1 hour
Status: VERIFIED FIXED
Alias: None
Product: Android
Classification: Xamarin
Component: BCL Class Libraries (show other bugs)
Version: 4.16.0
Hardware: PC Mac OS
: High major
Target Milestone: 4.18.1
Assignee: Marek Habersack
URL:
: 23824 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-09-26 09:06 UTC by Mart Roosmaa
Modified: 2014-11-04 01:06 UTC (History)
36 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
TestCase displaying DateTime.Now (10.06 KB, application/zip)
2014-09-26 09:06 UTC, Mart Roosmaa
Details
Correct results on run on the iOS simulator (37.27 KB, text/plain)
2014-10-03 15:15 UTC, Randy
Details
wrong results run on an Samsung android tablet (22.53 KB, text/plain)
2014-10-03 15:16 UTC, Randy
Details

Description Mart Roosmaa 2014-09-26 09:06:31 UTC
Created attachment 8206 [details]
TestCase displaying DateTime.Now

Since the last update to Xamarin.Android (stable channel) DateTime.Now started returning time 1h less than the actual time. (DST problems?) This happens only on Android target (iOS is fine).

Xamarin Studio - 5.4 (build 240)
Xamarin.Android - 4.16.0

I've attached a simple test case. My phone is in the Europe/Helsinki timezone, the time on the status bar is shown as 16:00, but the time on the button is shown as 15:00. 1 hour less.

It's kind of a serious problem for our app as we're a time tracking app. Until this bug is fixed, where can I download the previous (Android) release to make a hotfix release for our app?
Comment 1 Mart Roosmaa 2014-09-26 09:13:21 UTC
Related to #22955 ?
Comment 2 Mart Roosmaa 2014-09-26 09:53:00 UTC
Got earlier versions of Xamarin.Android from email support (kudos to Allie for quick responses).

Everything works as expected with Xamarin.Android 4.14.0-55. DateTime.UtcNow stop working (correctly) in 4.16.0-14.
Comment 3 Udham Singh 2014-09-26 14:10:20 UTC
I have checked this issue and able to reproduce this. To reproduce this issue I have used the sample attached in bug description. I have followed the steps mentioned below to reproduce this issue.

1. Open the sample attached in bug description in XS.
2. Set the device/emulator timezone to 'Europe/Helsinki timezone'.
3. Run the application.

Screencast : http://www.screencast.com/t/Dw7D6oKZkkS

Environment Info ;

=== Xamarin Studio ===

Version 5.4 (build 240)
Installation UUID: ce927b2a-2c07-44c5-b186-09cfdafba6dc
Runtime:
	Mono 3.8.0 ((no/45d0ba1)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 308000009

=== Xamarin.Android ===

Version: 4.16.0 (Business Edition)
Android SDK: /Users/xamarin76/Desktop/android-sdk-macosx
	Supported Android versions:
		1.6    (API level 4)
		2.1    (API level 7)
		2.2    (API level 8)
		2.3    (API level 10)
		3.0    (API level 11)
		3.1    (API level 12)
		3.2    (API level 13)
		4.0    (API level 14)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		4.5    (API level 21)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Apple Developer Tools ===

Xcode 6.0.1 (6528)
Build 6A317

=== Xamarin.iOS ===

Version: 8.0.0.62 (Business Edition)
Hash: 8bd8158
Branch: 
Build date: 2014-09-18 09:12:55-0400

=== Xamarin.Mac ===

Version: 1.11.0.1 (Business Edition)

=== Build Information ===

Release ID: 504000240
Git revision: 01786bc67c7024ec33d327ed27e4416d7a846f4e
Build date: 2014-09-17 10:58:48-04
Xamarin addins: 7cd7dfcd6b7b7b53281508954ec080f1cd153ad3

=== Operating System ===

Mac OS X 10.9.4
Darwin Xamarin76s-Mac-mini.local 13.3.0 Darwin Kernel Version 13.3.0
    Tue Jun  3 21:27:35 PDT 2014
    root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64
Comment 4 Mazzanti Luca 2014-09-30 03:14:24 UTC
Greetings, we are also working on a porting of a logistic system on android.
It synchronize with server, and we can't correctly use and display date.
I won't convert all usages of DateTime.Now in utc format, or show to users a not real last modify date.

In my opinion, the dateTime.Now failure is an high\blocking scenario, not only normal.

What can i do now? deploy it with the old version?
When will be covered? In a future release?
Thanks for your support, Mazzanti Luca.
Comment 8 Miguel de Icaza [MSFT] 2014-09-30 13:56:39 UTC
*** Bug 22648 has been marked as a duplicate of this bug. ***
Comment 9 Miguel de Icaza [MSFT] 2014-09-30 13:57:21 UTC
*** Bug 23170 has been marked as a duplicate of this bug. ***
Comment 10 adslcx 2014-10-03 04:49:59 UTC
This regression has blocked us from using any Xamarin.Android >= 4.16.0.

When can we get an ETA of this issue?
Comment 11 Randy 2014-10-03 15:14:39 UTC
I have also run into this problem using the beta channel version 4.18.0. This code shows the problem.

			// dst test code
			for (int year=2012; year<2015; year++)
			{
				var dst = TimeZone.CurrentTimeZone.GetDaylightChanges (year);
				Console.WriteLine ("dst: " + dst.Start.ToString ("g") + " -> " +dst.End.ToString ("g"));
				var tz = TimeZone.CurrentTimeZone;
				for (int month=1; month<13; month++)
				{
					for (int day=1; day<10; day++)
					{
						var localtime = new DateTime (year, month, day, 10, 00, 00, DateTimeKind.Local);
						var utctime = localtime.ToUniversalTime ();
						var offset = TimeZone.CurrentTimeZone.GetUtcOffset (localtime);
						var is_dst = TimeZone.CurrentTimeZone.IsDaylightSavingTime (utctime);
						Console.WriteLine ("offset: " + offset.ToString ("g") + "  local: " + localtime.ToString ("g") + " -> utc: " + utctime.ToString ("g") + (is_dst ? " DST" : ""));
					}
				}
			}		


The GetUtcOffset function is returning the wrong value between 10/2 and 11/1. It is returning -5 for eastern time which is the non-dst value but that range is still in dst.

I suspect code inside GetUtcOffset is using a month value that is 0-based (january=0) in a calculation that is expecting a 1-based (january=1) value. Oddly enough, the IsDaylightSavingTime function is returning the correct value.

This problem breaks ToUniversalTime (and I assume ToLocalTime) so that a local time converted to universal time is coming out 1 hour off when it is in the 10/2/2014 to 11/1/2014 date range.

The error ranges change on each year to match the day of the month when dot is supposed to end.

I will attach 2 debugger console files generated with the above code on an iOS simulator and a Samsung android tablet, running android 4.2.2
Comment 12 Randy 2014-10-03 15:15:33 UTC
Created attachment 8302 [details]
Correct results on run on the iOS simulator
Comment 13 Randy 2014-10-03 15:16:02 UTC
Created attachment 8304 [details]
wrong results run on an Samsung android tablet
Comment 14 Randy 2014-10-03 16:55:12 UTC
Reverting to Xamarin.android 4.14 solves all the DateTime problems.

Download link 

http://download.xamarin.com/MonoforAndroid/Mac/mono-android-4.14.0-55.pkg
Comment 15 Marek Habersack 2014-10-08 08:50:58 UTC
This is fixed in master/b5948c28726a889e82b4ee0dcb479332790435e0
Comment 16 mvandre 2014-10-08 10:49:57 UTC
Can someone explain how to determine when this fix makes it into a stable release?
Comment 17 Marek Habersack 2014-10-08 10:59:44 UTC
It will be mentioned in the release notes, along with the bug number.
Comment 18 mvandre 2014-10-08 11:08:57 UTC
Thanks, and what is the typical turn-around time for something like this?
Comment 19 Marek Habersack 2014-10-08 11:19:01 UTC
This fix is quite important so I hope we will be able to release it quite soon, hopefully not long after Evolve. Otherwise, the fix and the new version needs to go through the full QA cycle as well as through the Alpha and Beta releases. Depending on the testing results it may take up to 4 weeks.
Comment 20 Paul 2014-10-12 21:52:21 UTC
FYI, this bug applies to Windows platform as well.
Comment 21 Marek Habersack 2014-10-15 05:00:32 UTC
*** Bug 23824 has been marked as a duplicate of this bug. ***
Comment 22 Craig 2014-10-15 11:30:03 UTC
Please escalate this fix being released.  It's a substantial, obvious bug.  Should have been caught during testing.  You guys need to do a better job of testing in general.
Comment 23 Cody Beyer (MSFT) 2014-10-15 12:06:24 UTC
Confirmed this bug still exists with hotfix:

Recreation:

Create generic Android app
Set Emulator TimeZone to Australian Eastern Daylight Time

Run the following code:

var value = DateTime.UtcNow;

Console.WriteLine (System.TimeZoneInfo.ConvertTimeFromUtc (value, System.TimeZoneInfo.FindSystemTimeZoneById (System.TimeZoneInfo.Local.Id)));
Console.WriteLine (System.TimeZoneInfo.ConvertTimeFromUtc (value, System.TimeZoneInfo.Local));

The Console.WriteLines should be the same, however they are not. See Screenshot:

https://www.dropbox.com/s/ik0uuccv976bkdy/Screen%20Shot%202014-10-15%20at%209.05.08%20AM.png?dl=0

Thanks
Comment 24 mvandre 2014-10-15 12:18:00 UTC
I concur with craig. No software that uses date can be shipped with any version of xamarin that contains this defect.
Comment 25 Jamie 2014-10-15 12:21:50 UTC
Not true. I shipped with this defect using this workaround... https://gist.github.com/jamie94bc/ceac7fa8c0062345a6d5
Comment 26 Udham Singh 2014-10-15 13:11:26 UTC
I have checked this issue 4.18.0-38 and observed that if we set emulator/device TimeZone to 'Australian Eastern Daylight Time' then we are still getting the same issue, however for timezone 'Europe/Helsinki timezone' shows correct time.
Comment 27 David Schwegler 2014-10-16 16:35:49 UTC
I'm also affected (PDT, GMT-7). It's very unsettling that a fundamental bug like this could get into Xamarin.

Please communicate with your customers on issues of this importance. People have been talking about this on the forums for weeks without any Xamarin response, and it's been easily the most active topic on the front page: http://forums.xamarin.com/discussion/25093/dst-daylightsavingtime-issue-for-datetime-now
Comment 28 Mohit Kheterpal 2014-10-17 05:35:23 UTC
I have checked this issue with attached project and observed that when we use XA 4.18.0-39 then it shows correct date and time after setting "Australian Eastern Daylight Time" and "Europe/Helsinki timezone" on device.

Screencast after using code in comment 23 : http://screencast.com/t/X0bViRi8wbJ

Hence closing this issue.
Comment 29 Mohit Kheterpal 2014-10-17 11:06:19 UTC
I have checked this issue using code provided in comment 11 and setting time AEDT(Australian Eastern Daylight Time) then it shows wrong output.

Application output : https://gist.github.com/Mohit-Kheterpal/eaf34ef9e39818559d90

The first line of the application output shows the DST time : 10/2/2012 2:00 AM -> 4/7/2013
and it prints from 10/2 to 12/9. This is wrong.

Hence reopening this issue.
Comment 30 David Schulte 2014-10-21 12:27:15 UTC
When significant issues like this occur, could someone from Xamarin PLEASE send out email to their clients, or at least those registered with bugzilla.xamarin.com accounts? I just stumbled across this bug myself and we are currently running an application production which is obviously saving wrong date/time values.
Thanks,
Dave
Comment 31 Jonathan Pryor 2014-10-23 16:21:57 UTC
Fixed in monodroid/f60c21c0 and monodroid-4.18-series/35e1a551.
Comment 33 Rodolfo Redolfi 2014-10-27 05:52:15 UTC
Hi, guys,
hope this fix (hopefully working) get out soon, because the workaround I posted when I opened this bug, starting from this morning, gives me the WRONG time (one hour ahead), because here in Italy daylight save mode has been switched off.
I'm reverting to the old code, that naturally works well, today, but dones't make my customer happy, because he has to update all the tablets running my application.

Best Regards.
Rodolfo.

PS: all of us are hoping not to have to correct the code next year, when the daylight saving mode will come back...
Comment 34 Mohit Kheterpal 2014-10-27 12:53:36 UTC
I have checked this issue by using code provided in comment 11 and this issue is working fine.

I am not getting the issue that I had mentioned in comment 29, now application output is correct.


And I have also checked this issue with attached project and observed that it shows correct date and time after setting "Australian Eastern Daylight Time" and "Europe/Helsinki timezone" on device.

Xamarin.Android 4.18.1-1 and Xamarin Studio 5.5.3.6

Hence closing this issue by marking it as verified.
Comment 35 Olaf Bartelt 2014-10-27 13:43:21 UTC
Did you try to set back the date to before the 26th of October to verify? Because daylight savings time (which contributed to/resulted in the bug) has ended yesterday?

I'd really like a confirmation, too, that a bug has indeed been found and fixed since the last time it was allegedly fixed...
Comment 36 Craig 2014-10-27 14:07:00 UTC
The problem seemed to be most visible when formatting/printing DateTime values, but please ensure that it is also parsing DateTime values correctly too.
Comment 37 Rodolfo Redolfi 2014-10-28 05:14:24 UTC
Hi, Olaf,
just tried and the datetime is correct, even switching back to 24-25 october.
Also there are the correct delta between DateTime.Now and DateTime.UtcNow switching back and forth the dates across the daylight saving date.
Very strange.
I've also verified that the apk I released to my customer (build 27) when we discovered the bug works well in daylight save mode and not in standard mode, while the one I released yesterday morning (build 28) works correctly in either modes. Is there a chance to obtain the library versions from an apk, or a log (should exist, if I remember well) to know which library version was installed in my system when was generated the apk ver. 27 ?

Please find below my current Xamarin infos :
=== Xamarin Studio ===

Version 5.5.2 (build 0)
Installation UUID: b366c44a-552c-4074-9138-ff0ca63727f8
Runtime:
	Microsoft .NET 4.0.30319.18444
	GTK+ 2.24.22 (MS-Windows theme)
	GTK# 2.12.26

=== Xamarin.Android ===

Version: 4.18.0 (Business Edition)
Android SDK: C:\Users\Rodolfo\AppData\Local\Android\android-sdk
	Supported Android versions:
		2.1   (API level 7)
		2.2   (API level 8)
		2.3   (API level 10)
		3.1   (API level 12)
		4.0.3 (API level 15)
		4.1   (API level 16)
		4.4   (API level 19)
Java SDK: C:\Program Files\Java\jdk1.6.0_39
java version "1.6.0_39"
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)

=== Build Information ===

Release ID: 505020000
Git revision: a5887be38215a6cdd3f349e102ef82a1c4f950a4
Build date: 2014-10-14 12:21:34-04
Xamarin addins: 069ddd29bb70a42238142eee9bac21a5e4b2f9f9

=== Operating System ===

Windows 6.1.7601.65536

Best Regards.
Rodolfo.
Comment 38 Olaf Bartelt 2014-10-28 05:33:32 UTC
Great, thanks! :-)

So in which build exactly is that fixed in the 4.18 tree? I have 4.18.0.38 and don't seem to have that problem anymore, but I want to make sure that I ship correct binaries to my customers ;-)
Comment 39 Jonathan Pryor 2014-10-28 11:46:20 UTC
@Olaf: 4.18.0.38 does NOT contain the fix; you would need 4.18.0.41, which hasn't been released.

Please wait for the forthcoming 4.18.1 release, which will contain the fix.
Comment 40 Olaf Bartelt 2014-10-28 13:45:46 UTC
@Jonathan: thanks for the info! Strange that it works with 4.18.0.38 (since I updated sometime around the 23rd of October)...

Note You need to log in before you can comment on or make changes to this bug.