Bug 23170

Summary: Invalid current timezone in ios8
Product: iOS Reporter: Andrei <gurux13>
Component: Xamarin.iOS.dllAssignee: marcos.henrich
Status: RESOLVED FIXED    
Severity: major CC: cnordvik, cody.beyer, gurux13, marcos.henrich, miguel, mono-bugs+monotouch, Rajneeshk, rolf
Priority: High    
Version: master   
Target Milestone: Untriaged   
Hardware: Macintosh   
OS: Mac OS   
Tags: Is this bug a regression?: ---
Last known good build:
Attachments: Screenshot of timezone info

Description Andrei 2014-09-18 18:55:34 UTC
Created attachment 8114 [details]
Screenshot of timezone info

After upgrading to iOS 8 on our device we get an invalid current time zone. It is always 1hr in the past. 

In short, DateTime.Now returns date that is 1hr in the past. 

Consider the following code:

Console.WriteLine(DateTime.Now.ToString("O"));

This line has to output current date and time with timezone info. I currently reside in Moscow, so I expect it to be +04:00, however it is +03:00. The printed local time is 1 hour in the past (UTC time is correct).

The same code line in iOS 7 outputs the correct timezone (+04:00). 

However on the same device the following code in ObjC:

NSDateFormatter *dateformate=[[NSDateFormatter alloc]init];
    [dateformate setTimeStyle:NSDateFormatterLongStyle];
    NSString *date = [dateformate stringFromDate:[NSDate date]]; // Convert date to string
    NSLog(@"date: %@",date);

returns the correct date with proper timezone.

I've attached a screenshot of a simple test app that outputs time info. The code is as follows:

string val = string.Format(
"Now local: {0},\n" +
"Now UTC: {1},\n" +
"TZ offset: {2},\n" +
"TZ std name: {3}\n" +
"TZ dst name: {3}\n" +
"TZ is std: {4}",
DateTime.Now.ToString ("O"),
DateTime.UtcNow.ToString ("O"),
TimeZone.CurrentTimeZone.GetUtcOffset (DateTime.Now).TotalHours,
TimeZone.CurrentTimeZone.StandardName,
TimeZone.CurrentTimeZone.DaylightName,
TimeZone.CurrentTimeZone.IsDaylightSavingTime (DateTime.Now));
lbLabel.Text = val;
Console.WriteLine (val);

The code outputs data in the wrong order, but it is clear that framework thinks it's UTC+3.
Comment 1 Andrei 2014-09-18 19:02:42 UTC
I have tested it on Xamarin.iOS 7.2.6 and 8.0.0.62 (beta). Same results.
Android version does not seem to have this bug.
Comment 2 Cody Beyer (MSFT) 2014-09-18 19:27:11 UTC
I have confirmed the existence of this bug
Comment 3 Rolf Bjarne Kvinge [MSFT] 2014-09-19 09:44:31 UTC
Marek, can you have a look?
Comment 4 Andrei 2014-09-20 15:34:47 UTC
After some investigation I've got the following. The invalid timezones are returned in these cases: 
IRKT (8 instead of 9), MAGT (10 instead of 12), MSK (3 instead of 4), OMST (6 instead of 7), SAKT (10 instead of 11)

All these timezones will become valid once the corresponding Russian law becomes active, and that's not until 26th of October. It seems that the runtime asks of current timezone in some date-independent way and the system returns what timezone will be current in some distant future.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2014-09-22 06:20:36 UTC
This is probably because Russia had a multi-year DST (from 2011 to 2014 [1]), so when Mono tries to find the DST period in 2014, the logic fails, because DST only ends in 2014, it never started.

[1] http://www.timeanddate.com/news/time/russia-reintroduces-dst-2014.html
Comment 6 Christer Nordvik 2014-09-25 08:15:05 UTC
Any chance of getting this into a release? We calculate elapsed time based on DateTime.Now compared to a server date and this fails for all users with the Moscow timezone.
Comment 7 Miguel de Icaza [MSFT] 2014-09-30 13:57:21 UTC

*** This bug has been marked as a duplicate of bug 23405 ***
Comment 8 Miguel de Icaza [MSFT] 2014-09-30 14:09:51 UTC
Reopened, not a duplicate, just similar in spirit.
Comment 9 marcos.henrich 2014-10-04 13:14:04 UTC
Hi Andrei, Christer,

Thank you for the detailed bug report.

The pull request for this issue can be found in the link below.
https://github.com/mono/mono/pull/1321

@Christer it can take a while before the fix gets into a release. Nonetheless once the fix is approved we can provide you a fixed build.
Comment 10 marcos.henrich 2014-10-28 14:25:59 UTC
Fixed in master 137718d9b4b5e65065445ed89b33a5a4f376e6b9.
https://github.com/mono/mono/commit/137718d9b4b5e65065445ed89b33a5a4f376e6b9