I am a developer in Belgium, with current timezone UTC+1:00. When I create a business closure rule for Christmas (24 hours starting from 25/12/2013 00:00:00 local time, 24/12/2013 23:00:00 UTC), I enter 25/12/2013 as the start date and check the "lasts entire day" checkbox in the Business Closures wizard. I am in the same building as the CRM server.
I then need to parse the business closures and 2 custom entities to a 3rd custom entity which manages the schedule for employees who don't have a CRM license attached. When I read the business closure calendar rules using a LINQ request and early binding, it turns out that CRM saved the 25/12/2013 00:00:00 (which is local time) into the UTC field without first converting it to UTC time. It does not do this for the other entity: If I enter 16/12/13 00:00:00 local time in a date field in one of the custom entities, it saves this as 15:12/13 23:00:00 UTC time, and preserves the local time in the correct field.
This has the consequence that in the 3rd custom entity, records generated from a custom entity have their date field set to 00:00:00 local time, while the records generated from the business closure calendar rule have their date field set to 01:00:00 local time. While this discrepancy is adjusted for relatively easily by subtracting 1 hour from the calendar rule generated field, it does feel like a bug.
When I look in the database itself, I notice that business closure dates are seemingly entered in the utc field without first being converted to UTC. Christmas and New Years Day are entered as midnight UTC and 01:00:00 local time, while they should be 23:00:00 UTC and midnight local time. Dates entered after the DST change to summer time are entered as midnight UTC and 02:00:00 local time, while they should be 22:00:00 UTC and midnight local time. I can imagine that for an installation in New York (UTC-5:00), Christmas and New year are entered as 00:00:00 UTC and 19:00:00 local the day before.
Is there a specific cause for this discrepance in date management?