I believe this is a bug since it is causing unexpected results.
I have a grid which is bound client-side to a web service. It would appear that datetime columns are being displayed differently, depending on the user's clock settings. In my scenario, my grid has two such columns (declared below).
<telerik:GridDateTimeColumn HeaderText="Svc. Date" DataField="ServiceDate" DataType="System.DateTime" DataFormatString="{0:MM/dd/yy}" AllowFiltering="false">
<HeaderStyle width="80px" HorizontalAlign="Left" BorderStyle="None"></HeaderStyle>
</telerik:GridDateTimeColumn>
<telerik:GridDateTimeColumn HeaderText="Created When" DataField="CreatedWhen" DataType="System.DateTime" DataFormatString="{0:MM/dd/yy hh:mm:ss tt}" AllowFiltering="false">
<HeaderStyle width="140px" HorizontalAlign="Left" BorderStyle="None"></HeaderStyle>
</telerik:GridDateTimeColumn>
For users who are in the Central US timezone, the "ServiceDate" column is showing as one day earlier, and the "CreatedWhen" column is showing as one hour earlier. When they switch their computer clock to Eastern Timezone (the correct zone for the data being retrieved), then the ServiceDate and CreatedWhen columns appear correctly.
Looking at the json being used to bind the grid to, for one row, these are the values being retrieved from the database...
"ServiceDate":"\/Date(1508904000000)\/", "CreatedWhen":"\/Date(1508942284530)\/"
So, it appears whatever mechanism the grid is using to convert these date objects to date literals is using the user's computer settings. Is this true?
I'm not sure this is a good implementation. The data being retrieved from the database is intended to be displayed as is. Any manipulations to customize for user timezone should be handled by the developer. After all, the grid does not know what timezone the data being retrieved is in, so how does it know how to convert to the user's local machine timezone?
In this case, the data being retreived was in Eastern US timezone. So, a date of '10/24/17', for instance, was being displayed as '10/23/17' (one hour earlier than 10/24/17 00:00:00, assumedly)
So, is there any way to prevent this behavior?