I don't suppose there's a way I'm not seeing to make the Scheduler component use UTC dates internally and for passing parameters to the IQueryable? I actually had my NHibernate mapping set up to use UTC DateTimes and it blew up when the generated query was executed because the DateTimeKind didn't match. (Utc vs. Unspecified)
If this turns into a feature request, Ideally I'd think one or two parameters should be added: First, a DisplayTimeZone parameter that would set the time zone to use for the Scheduler displays, which might automatically switch on use of UTC DateTime for the IQueryable and other input/output. A second parameter to activate UTC DateTimes as such, or specify a second, other "native" time zone could also be useful.
Even more ideally it could support DateTimeOffset, but that's probably much more work.
With a bunch of DateTime.Kind = Unspecified dates flying around (including in my NHibernate mapping if I change it) it's going to be near impossible to build an application to support working in different time zones... e.g. if someone adds an event on California time, I'd like someone looking at it in New York to see it three hours different on their own display.
You can probably use the LoadData event in this case and convert the dates as you want. The Radzen Scheduler does not do any date time manipulations as there is no "best" way - different users have different requirements.
Ahh... that is true. I was so caught up in the coolness of being able to hook it directly to the IQueryable<T> that I forgot about the LoadData<T> option. That will do fine, for now at least.
I'd still--personally--strongly recommend adding optional support for UTC dates in API usage with a local time zone specifiable for display. That's basically what I'll be implementing by hand in LoadData and a bunch of conversion in the ViewModel, which would otherwise be unnecessary.
I'd still--personally--strongly recommend adding optional support for UTC dates in API usage with a local time zone specifiable for display.
That would need to be two options. One for enabling UTC (how should dates be converted to UTC - by changing their kind or by converting them to UTC?) and one for specifying a timezone (again how should be dates coming from the DB treated when converting to the timezone - as local, UTC or unspecified?). We can't really make those decision on the developer's behalf we decided to stay away from them for now.
Thanks for the feedback. I found something related though that probably really should be considered a bug.
I implemented OnLoadData(...) as suggested, with this implementation to always be able to work with UTC dates:
var startUtc = TimeZoneInfo.ConvertTime(args.Start, UserService.CurrentUser.TimeZone, TimeZoneInfo.Utc);
var endUtc = TimeZoneInfo.ConvertTime(args.End, UserService.CurrentUser.TimeZone, TimeZoneInfo.Utc);
And this worked fine for RadzenMonthView--specifically, because args.Start and args.End were of DateTimeKind.Unspecified. Then, when I switched to RadzenWeekView, suddenly this threw an exception:
System.ArgumentException: The conversion could not be completed because the supplied DateTime did not have the Kind property set correctly. For example, when the Kind property is DateTimeKind.Local, the source time zone must be TimeZoneInfo.Local. (Parameter 'sourceTimeZone')
Because RadzenWeekView was sending args.Start and args.End as DateTimeKind.Local... I think whichever one is used, the type should be consistent between the different views. I realize however that will be a potentially breaking change if anyone has written code that expects one kind or another (such as the above). For now I am working around the issue by explicitly forcing the arguments to be Unspecified:
var startUtc = TimeZoneInfo.ConvertTime(DateTime.SpecifyKind(args.Start, DateTimeKind.Unspecified), UserService.CurrentUser.TimeZone, TimeZoneInfo.Utc);
var endUtc = TimeZoneInfo.ConvertTime(DateTime.SpecifyKind(args.End, DateTimeKind.Unspecified), UserService.CurrentUser.TimeZone, TimeZoneInfo.Utc);