"Mexico Standard Time" is not supported

[David Cardós Uc]

Hello,

I'm using the SfSchedule with Xamarin.Forms running on Android and I want to define a custom timezone to display the list of appointments wich are in UTC.

When I try to use "Mexico Standard Time" (same as olson "America/Mexico_city") I got the following error :

System.ArgumentNullException: Value cannot be null.

Parameter name: destinationTimeZone

CallStack :

  0x11 in System.TimeZoneInfo.ConvertTime at /Users/builder/jenkins/workspace/xamarin-android-d15-9/xamarin-android/external/mono/mcs/class/corlib/System/TimeZoneInfo.cs:387,5 C#

  0x70 in Com.Syncfusion.Schedule.AppointmentHelper.ConvertTimeToAppointmentTimeZone C#

  0x8B in Com.Syncfusion.Schedule.AppointmentEngine.GenerateScheduleAppointments C#

  0x23 in Com.Syncfusion.Schedule.SfSchedule.GenerateAppointments C#

  0x10 in Com.Syncfusion.Schedule.SfSchedule.set_ItemsSource C#

  0x1F2 in Syncfusion.SfSchedule.XForms.Droid.SfScheduleMapping.OnSfSchedulePropertiesChanged C#

  0x3D in Syncfusion.SfSchedule.XForms.Android.SfScheduleRenderer.OnElementPropertyChanged C#

  0x12 in Xamarin.Forms.BindableObject.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\BindableObject.cs:173,7 C#

  0x2 in Xamarin.Forms.Element.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\Element.cs:339,4 C#

  0x11B in Xamarin.Forms.BindableObject.SetValueActual at D:\a\1\s\Xamarin.Forms.Core\BindableObject.cs:622,5 C#

  0x182 in Xamarin.Forms.BindableObject.SetValueCore at D:\a\1\s\Xamarin.Forms.Core\BindableObject.cs:422,5 C#

  0x51 in Xamarin.Forms.BindableObject.SetValue at D:\a\1\s\Xamarin.Forms.Core\BindableObject.cs:572,4 C#

  0x5 in Xamarin.Forms.BindableObject.SetValue at D:\a\1\s\Xamarin.Forms.Core\BindableObject.cs:122,4 C#

  0x8 in Syncfusion.SfSchedule.XForms.SfSchedule.set_DataSource C#

Could you help me with this issue please ?

Kindly,

David

[Subburaj Pandian Veluchamy]

Hi David, 

 

Thank you for contacting Syncfusion support. 

 

Based on the provided information, we have checked the mentioned issue “Throws exception when setting Mexican Standard Time to the Schedule TimeZone” in Xamarin.Forms. Schedule TimeZone property value is string and when setting different time zone which has not added in the source has throws exception. Based on the Microsoft standard, we have covered all the TimeZone and concluded as the timezone values, for setting TimeZone you need to set the particular string.

Please refer the following values for Mexican time zone, 

 

[Values]
"Mountain Standard Time (Mexico)", "America/Chihuahua"
"Pacific Standard Time (Mexico)", "America/Santa_Isabel"

 

[Xaml] 

    <schedule:SfSchedule x:Name="scheduler"  

                         DataSource="{Binding Appointments}"  

                         TimeZone="Mountain Standard Time (Mexico)"                        

                         ScheduleView="WeekView"> 

    </schedule:SfSchedule> 

 

  

In our Schedule SampleBrowser Appointment Editor sample, we have mentioned this collection list of TimeZones. You can refer the sample by the following link, 

 

SampleBrowser sample link: https://github.com/syncfusion/xamarin-demos/blob/master/Forms/Schedule/Schedule/Samples/AppointmentEditor/ViewModels/TimeZoneCollection.cs 

 

Since these details not added in our User Guide documentation, we have logged task for the same. We will update these details as early as possible (Maximum end of this week April 2019).

We have prepared sample for the same with Mexican time zone,

Sample link: Schedule_TimeZone

We hope this helps. 

 

Regards,
Subburaj Pandian V 

[David Cardós Uc]

Hi,

Thanks for your answer, when you say "Based on the Microsoft standard, we have covered all the TimeZone and concluded as the timezone values" can you tell me which Microsoft page give this information please ? (list of All Microsoft Standard TimeZone)

In fact, when I check this link https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/default-time-zones I can see the Time zone I'm looking for ("Central Standard Time (Mexico)") but if I check your page for supported time-zones I don't see the Central timezone for Mexico 

https://help.syncfusion.com/xamarin/sfschedule/timezone

For Mexico we have three reference time-zones Pacific (UTC -8:00 / -7:00), Central (UTC -6:00 / -5:00) and Mountain (UTC -7:00 / -6:00).

Can you help me with that please ?

Also, can you tell me how I can get the full supported time zone list programmatically ?, this could be very helpful to prevent this error when retrieving the timezone name to use from an external application (in my case a PHP application).

Thanks,

David

[Subburaj Pandian Veluchamy]

Hi David, 

 

Thank you for the update. 

 

Your requirement of setting Central Standard Time (Mexico) can be achieved by setting concern string to the Schedule Time-Zone. Mountain Standard Time (Mexico) is equivalent of Central Standard Time (Mexico). Since Central Standard Time (Mexico) has three different regions UTC -7, UTC -6, UTC -5 as you mentioned you need set the exact region to set the specific time zone.  

 

UTC	Schedule Time Zone string	Region
UTC -7	Mountain Standard Time (Mexico)	America/Chihuahua
UTC -6	US Mountain Standard Time  Mountain Standard Time	America/Denver (Daylight saving time +1)
UTC -5	Eastern Standard Time	America/New_York

 

In MSDN also there is one time zone for Mexico which is Central Standard Time (Mexico). Based on the region/Time zone, you need to set the specific string Time-zone. We have already added the Time zone string value based on region and time zine in our UG documentation. Since we didn’t add these UTC offset details in the concern time zone regions in our UG documentation, we have considered and created task for the same. We will update the same as soon as possible, within our upcoming 2019 Volume 2 release. 

Please let us know, if you have any concern. 

 

Regards,
Subburaj Pandian V   

[David Cardós Uc]

Hello,

Thanks for your answer an sorry for my reply delay, the problem with timezones is not only the daylight saving offset, it is also about when the time changes (and historical changes), because it depends on  political decisions for each country, thats why Mexico and US will have different dates for summer time change even if GTM are the same and summer time is the same.

I must say that I don't really understant why you have implemented your own logic to manage conversions, because it is really hard to keep DST up to date, because every year you could have changes around the World, for exemple in Europe, there was a recent change that will allow to each country in the EU to decide if they keep or not the summer time. In France it will be removed the next year I think.

Also, I've made new researchs and I discovered that Mexico (yes I'm from Mexico and even me doesn't know about this change, five years ago) has now 5 different timezones (https://www.worldtimezone.com/dst_news/dst_news_mexico11.html).

If you check the Xamarin Forms Help blog (https://xamarinhelp.com/time-zones-xamarin-forms/) you will see that Android and iOS shares the same standard and it is only Windows that uses a different standard (their own standard).

Thats means that your build-in logic is only usefull if we develop for windows applications and I think that the big mayority of Xamarin Forms developpers uses this framework for Android and iOS, not for WPF/UWP.

In fact, I think that is a lot easier for you to have a default timezone name handler that will only use the system TimeZoneInfo.FindTimeZone method and WPF/UWP developpers can implement their own converter (based on Xamarin post).

I think something like that :

public interface ITimeZoneHandler 

{

  TimeZone Parse(string timezone);

}

And we can set a custom handler by calling : 

 Xamarin.Core.TimeZoneHandler.SetCustomHandler(new MyWonderfulTimeZoneHandlerBasedOnTimeZoneDB())

Only for fun: https://www.youtube.com/watch?v=-5wpm-gesOY

Regards,

David

[Subburaj Pandian Veluchamy]

Hi David, 

 

Thank you for the update. 

  

Currently, we are analyzing on this TimeZone query with Schedule. We will validate and update you the further details in two business days (May 22, 2019). We appreciate your patience until then. 

 

Regards,
Subburaj Pandian V    

[Subburaj Pandian Veluchamy]

Hi David,  

  

Thank you for your patience. 

 

We have implemented TimeZone feature based on the Microsoft standard and we have covered all the TimeZone and concluded as the time-zone values. As mentioned, for setting TimeZone you need to set the particular string. We have listed those time-zone details in our UG documentation. As we mentioned earlier, we update these time-zones along with its UTC values as early as possible.  

 

Based on the Microsoft time-zone list, you can get all the time-zones in Schedule as well. We have calculated and processed based on the framework Time offset only. So, that date will process, and render based on the day light saving time as well.

Naming alone different from the standard time and offset values can be calculated and Time will be same for the specific time zone. For example, if Eastern Standard Time or S.A. Pacific Standard Time is your time zone to set, naming alone may be vary time-zone value should be same (UTC-5:00).  

 

Based on the required offset value (UTC) you can set your required TimeZone (String) in Schedule and we have covered all the Time-Zone’s. We will update this UTC values with the concern time-zone string value in our UG documentation as early as possible.  

 

Regards,
Subburaj Pandian V     

[David Cardós Uc]

Hi,

Sorry, I think that I mixed somme things in my previous comment.

But, I don't think that declared TimeZones are enough to cover all TimeZones conversions, because as I've said before the date of this changes depends on every Contry or region.

You say "Naming alone different from the standard time and offset values can be calculated and Time will be same for the specific time zone. For example, if Eastern Standard Time or S.A. Pacific Standard Time is your time zone to set, naming alone may be vary time-zone value should be same (UTC-5:00).  " 

But is not always true, because the begin and end date for summer time is not the same, depending on the date to convert you will have a different offset (because one will take summer time and the other wont)

Please check the following example:

I've compared the "S.A. Pacific Standard Time" and "Eastern Standard Time" timezones.

Today the UTC offset is the same, but it wasn't five months ago, because of summer time begin date.

https://dotnetfiddle.net/zMr4CC

Regards,

David

[Subburaj Pandian Veluchamy]

Hi David,   

   

Thank you for the update. 

We have checked the mentioned Time-zones (S.A. Pacific Standard Time" and "Eastern Standard Time") with Schedule and it is working fine as expected from our end. As you mentioned, yes - Day light saving time / summer time can be vary based on time-zones. We have handled time zones from framework DateTime, not handled manually. So, it is working based on the certain time zone with day light saving time / summer time. We deeply appreciate the time you took to elaborate details and query with this feature. 

 
Can you please check the same with given sample by changing the system / mobile Date Time with concern date time and let us know if you face any issue with the platform details? It will be helpful for us to check on it and provide you the solution. 

 

Regards,
Subburaj Pandian V