Bug 13977 - System.Globalization.ThaiBuddhistCalendar being linked away
Summary: System.Globalization.ThaiBuddhistCalendar being linked away
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 6.4.0
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Sebastien Pouliot
: 14150 ()
Depends on:
Reported: 2013-08-14 14:23 UTC by Bryan Moulton
Modified: 2013-10-01 20:22 UTC (History)
5 users (show)

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

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:

Description Bryan Moulton 2013-08-14 14:23:53 UTC
In reference to case #42390

Even after selecting all regions in the Internationalization window, the ThaiBuddhistCalendar is still being linked away during compilation.
Comment 1 Sebastien Pouliot 2013-08-14 15:17:48 UTC
The extra calendars (i.e. ThaiBuddhistCalendar, UmAlQuraCalendar and HijriCalendar) are opt-in* because the linker cannot detect if they are required (or not) by an application.

Right now you need to preserve them but it makes sense to attach this the Internationalization settings.
Comment 2 Sebastien Pouliot 2013-08-14 15:37:16 UTC
In the mean time adding those lines to an application will ensure they (all 3) are preserved.

		static Type Thai = typeof (System.Globalization.ThaiBuddhistCalendar);
		static Type UmAlQura = typeof (System.Globalization.UmAlQuraCalendar);
		static Type Hijri = typeof (System.Globalization.HijriCalendar);
Comment 3 Sebastien Pouliot 2013-08-21 13:09:39 UTC
*** Bug 14150 has been marked as a duplicate of this bug. ***
Comment 4 Neal 2013-08-28 09:51:51 UTC
I've got the issue as well, watching this thread for the perma'fix
Comment 5 Christer Nordvik 2013-09-13 03:10:56 UTC
Any update on this? We just launched an update of our app and got 50 crash reports in a single day with this crash :-( Guess we'll add the workaround and issue an update but would have been nice if this had been fixed...
Comment 6 Sebastien Pouliot 2013-09-13 08:12:10 UTC
Christer, which version did you use ?

It should not crash anymore since 6.4.4+ even without the workaround (which only make sure the right, and not the default, calendar will be used wrt culture).
Comment 7 Christer Nordvik 2013-09-13 08:21:11 UTC
I used because my subscription just expired (a few days ago) and I was too lazy to upgrade. Sorry about that! Will fix my subscription and update it.
Comment 8 Christer Nordvik 2013-09-17 05:54:43 UTC
I updated, submitted a new app with both workaround and latest code and got an expedited review request passed. And it still crashes :-(

Device info: iPhone - Unknown - 6.1.4, timezone=18000,
19:30:48: Calendar not found, if the linker is enabled make sure to preserve this type: System.Globalization.ThaiBuddhistCalendar -  at System.Globalization.CultureInfo.CreateCalendar (Int32 calendarType) [0x00000] in <filename unknown>:0
  at System.Globalization.CultureInfo.get_Calendar () [0x00000] in <filename unknown>:0
  at System.Globalization.DateTimeFormatInfo.get_Calendar () [0x00000] in <filename unknown>:0
  at System.DateTimeUtils.ToString (DateTime dt, Nullable`1 utc_offset, System.String format, System.Globalization.DateTimeFormatInfo dfi) [0x00000] in <filename unknown>:0
  at System.DateTimeUtils.ToString (DateTime dt, System.String format, System.Globalization.DateTimeFormatInfo dfi) [0x00000] in <filename unknown>:0
  at System.DateTime.ToString (System.String format, IFormatProvider provider) [0x00000] in <filename unknown>:0
  at System.DateTime.ToString (System.String format) [0x00000] in <filename unknown>:0
Comment 9 Sebastien Pouliot 2013-09-17 08:09:28 UTC
Christer, something went wrong in your build/release process as the string "Calendar not found, if the linker is enabled make sure to preserve this type:" does not exists anymore in 6.4.4 (and later). 

Just doing this command, inside a terminal window, will return nothing:

   strings /Developer/MonoTouch/usr/lib/mono/2.1/mscorlib.dll | grep "Calendar not found"

Also it won't throw if it does not find the request Calendar [1], it will simply returns the default calendar.

[1] https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Globalization/CultureInfo.cs#L1007
Comment 10 Christer Nordvik 2013-09-17 11:28:25 UTC
If I go to "About" I get the following: 
Version: (Business Edition)
Hash: 1336a36
Build date: 2013-10-09 11:14:45-0400

If I do the command in the terminal window I get a lot of results. Any ideas what can be wrong with my environment? 
strings /Developer/MonoTouch/usr/lib/mono/2.1/mscorlib.dll | grep "Calendar
not found"

Comment 11 Sebastien Pouliot 2013-09-17 11:43:26 UTC
Did you put the command on a single-line ?

i.e. Bugzilla posted the command on two lines - but it must be executed on a single one, like:

> strings /Developer/MonoTouch/usr/lib/mono/2.1/mscorlib.dll | grep "Calendar not found"

Your result above seems to be where the string "Calendar" was found.

You can also try to find the same (complete) string inside the .app you submitted. If you find it there (and not in mscorlib.dll) then you did not submit something built with the latest Xamarin.iOS (old build?)
Comment 12 Christer Nordvik 2013-09-17 11:46:55 UTC
Sorry about that, I must have messed up the build in some way. Feel free to close this issue.
Comment 13 Sebastien Pouliot 2013-10-01 20:22:20 UTC
Fixed in master 9fcb926cf7b3ed6946ea3087d24c97e10b82b8f8

For future releases the extra calendars will be included automatically if the matching i18N option is used. Otherwise it will (continue to) default to the GregorianCalendar (which is an optional calendar for them).

* Other

* MidEast