Bug 23170 - Invalid current timezone in ios8
Summary: Invalid current timezone in ios8
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Xamarin.iOS.dll (show other bugs)
Version: master
Hardware: Macintosh Mac OS
: High major
Target Milestone: Untriaged
Assignee: marcos.henrich
URL:
Depends on:
Blocks:
 
Reported: 2014-09-18 18:55 UTC by Andrei
Modified: 2014-10-28 14:25 UTC (History)
8 users (show)

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


Attachments
Screenshot of timezone info (58.70 KB, image/png)
2014-09-18 18:55 UTC, Andrei
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

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