I understand that best practice is to store DateTime values as UTC.
Can someone tell me how this works on a ASP.NET Core Web Page and API? If I get DateTime.Now on an ASP.NET Core Web Page does this represent the Server timestamp or the Browser/Client timestamp?
I have a REST API eco-system. Should my rest methods assume that datetime values are UTC? If so, is there a way to validate that the value is UTC? If not, how would I know the browser/client's time zone to do the conversion? Where should this conversion
happen?
as DateTime.Now is a c# call, its running on the server like all controller, view & razor page code. The .net datatime object is the number of ticks (100 nan-seconds) since 1/10001 (UTC).
if in javascript you call new Date() you will get a datetime object which is the number of milliseconds since 1/1/1970 UTC (unix timestamp) based on the browsers clock and timezone.
in both cases the binary value is UTC. when converted to or from a string a timezone is required. if you have a REST api using JSON, if you have a date/time property it will most likely be a string rather than the number ticks or milliseconds from a know
time. Ambiguity is introduced if the string does not include the time zone.
when the javascript JSON.serialize() method serializes a Date value, its in ISO 8601 format (which includes the offset from UTC). when .net serializes a DateTime type it depends on the serializer used, and its settings. the builtin core Json serializer also
use ISO 8601 (unlike the old one that produced "/Date(<milliseconds>)/". NewtonSoft has several settings.
note: ISO 86401 is not a standard supported by the DateTime object itself. You will need to use a custom style.
My 2c is that it is better to use and store DateTimeOffset rather than DateTime with an assumption of it being UTC. That way times are stored in a format which is more easily understood by the client. For example, a particular point in time could be stored
as 2019-11-16 10:00 +11:00 (if I provide it) or the exact same time could be stored as 2019-11-15 23:00 +0:00 by a Londoner or 2019-11-15 18:00 -5:00 by a New Yorker. All three represent the same instant (I'm not getting into relativity here …) The advantage
is that if the time is displayed back to the user with no processing then they have a better chance of being able to interpret it because the 'wall clock' part is what they expect.
DateTime.Now will be server time. DateTimeOffset.UtcNow is what you want for server events. Stored times should have both the point in time and the offset stored. I use DatTimeOffset.UtcNow if the api is recording something that is independent of the
user (when the application started up, when a background job ran, etc). I get the client to provide their timezone info either as a name or an offset..
If the client wishes to have a point in time recorded then they should provide a DateTimeOffset. It is up to the client to choose whether they use their local offset (with any daylight saving adjustment) or UTC.
When client displays a point in time they will receive a DateTimeOffset from your api and can choose to display it in whatever timezone they want but if you store with the client's offset then the 'wall clock' component will be automatically correct.
Is ASP.NET smart enough to display back the dates in the user's local time zone or do I need to perform my own conversions? So, even though I store the values as "Server Time" will the conversion happen automatically in the client/browser?
Is ASP.NET smart enough to display back the dates in the user's local time zone or do I need to perform my own conversions? So, even though I store the values as "Server Time" will the conversion happen automatically in the client/browser?
Depends where the code is running. JavaScript will have the users timezone because JavaScript can see the user's system clock. If the code is running on the server then the code only has access to the server's clock. Either you have to write JavaScript
code to get the user's timezone or ask the user for their timezone and store the information in a database.
Member
3 Points
9 Posts
DateTime.Now - Does anyone really know what time it is?
Nov 15, 2019 07:04 PM|jlpm|LINK
I understand that best practice is to store DateTime values as UTC.
Can someone tell me how this works on a ASP.NET Core Web Page and API? If I get DateTime.Now on an ASP.NET Core Web Page does this represent the Server timestamp or the Browser/Client timestamp?
I have a REST API eco-system. Should my rest methods assume that datetime values are UTC? If so, is there a way to validate that the value is UTC? If not, how would I know the browser/client's time zone to do the conversion? Where should this conversion happen?
Please give me best practices...
Thanks for your help,
JP
All-Star
54204 Points
13635 Posts
Re: DateTime.Now - Does anyone really know what time it is?
Nov 15, 2019 09:17 PM|bruce (sqlwork.com)|LINK
as DateTime.Now is a c# call, its running on the server like all controller, view & razor page code. The .net datatime object is the number of ticks (100 nan-seconds) since 1/10001 (UTC).
if in javascript you call new Date() you will get a datetime object which is the number of milliseconds since 1/1/1970 UTC (unix timestamp) based on the browsers clock and timezone.
in both cases the binary value is UTC. when converted to or from a string a timezone is required. if you have a REST api using JSON, if you have a date/time property it will most likely be a string rather than the number ticks or milliseconds from a know time. Ambiguity is introduced if the string does not include the time zone.
when the javascript JSON.serialize() method serializes a Date value, its in ISO 8601 format (which includes the offset from UTC). when .net serializes a DateTime type it depends on the serializer used, and its settings. the builtin core Json serializer also use ISO 8601 (unlike the old one that produced "/Date(<milliseconds>)/". NewtonSoft has several settings.
note: ISO 86401 is not a standard supported by the DateTime object itself. You will need to use a custom style.
Participant
1080 Points
581 Posts
Re: DateTime.Now - Does anyone really know what time it is?
Nov 15, 2019 09:50 PM|PaulTheSmith|LINK
It depends … of course.
My 2c is that it is better to use and store DateTimeOffset rather than DateTime with an assumption of it being UTC. That way times are stored in a format which is more easily understood by the client. For example, a particular point in time could be stored as 2019-11-16 10:00 +11:00 (if I provide it) or the exact same time could be stored as 2019-11-15 23:00 +0:00 by a Londoner or 2019-11-15 18:00 -5:00 by a New Yorker. All three represent the same instant (I'm not getting into relativity here …) The advantage is that if the time is displayed back to the user with no processing then they have a better chance of being able to interpret it because the 'wall clock' part is what they expect.
DateTime.Now will be server time. DateTimeOffset.UtcNow is what you want for server events. Stored times should have both the point in time and the offset stored. I use DatTimeOffset.UtcNow if the api is recording something that is independent of the user (when the application started up, when a background job ran, etc). I get the client to provide their timezone info either as a name or an offset..
If the client wishes to have a point in time recorded then they should provide a DateTimeOffset. It is up to the client to choose whether they use their local offset (with any daylight saving adjustment) or UTC.
When client displays a point in time they will receive a DateTimeOffset from your api and can choose to display it in whatever timezone they want but if you store with the client's offset then the 'wall clock' component will be automatically correct.
All-Star
52363 Points
15601 Posts
Re: DateTime.Now - Does anyone really know what time it is?
Nov 16, 2019 12:27 AM|oned_gk|LINK
AFAIK DateTime.Now is System datetime of the web server
Suwandi - Non Graduate Programmer
Member
3 Points
9 Posts
Re: DateTime.Now - Does anyone really know what time it is?
Nov 21, 2019 03:25 PM|jlpm|LINK
Is ASP.NET smart enough to display back the dates in the user's local time zone or do I need to perform my own conversions? So, even though I store the values as "Server Time" will the conversion happen automatically in the client/browser?
All-Star
44851 Points
19387 Posts
Re: DateTime.Now - Does anyone really know what time it is?
Nov 21, 2019 03:47 PM|mgebhard|LINK
Depends where the code is running. JavaScript will have the users timezone because JavaScript can see the user's system clock. If the code is running on the server then the code only has access to the server's clock. Either you have to write JavaScript code to get the user's timezone or ask the user for their timezone and store the information in a database.