I have an asp.net site which displays various data from a SQL backend to users which are in different time zones, i.e. PST, GMT, etc.
How can I easily display the dates on the page but in the time zone that the users are in and not the raw SQL date format?
I know it has to do with globalization settings but I have never used that before.
Use two resource (.resx) files with a 'Format_DateTime' key. Have a value 'dd-mm-yyy HH:mm tt' for the default and a 'mm-dd-yyyy hh:mm tt' for en-US.
In your page, call MyDate.ToString(Resources.Format_DateTime) .
Related
I am currently exploring Learning locker which is a LRS and store XAPI statements .I see the timestamp in XAPI should follow ISO 8601 format .I see it can be represented as "2015-01-01T01:00Z" but how can I store the timezone information too like "2007-04-05T12:30−02:00".XAPI documentation suggests setting the timeozone but there is no clear way how we can do it .
Any clue on this will be helpful .
Generally the Z indicates a timezone, specifically the UTC timezone. It is preferred that all statement timestamps are stored using UTC and then if they need to be handled relative to a local timezone then that conversion happens at the point of need rather than via the stored data. If you must store it with the specific timezone then the format you showed with the -02:00 should work. NOTE: In the proposed (nearly accepted) version 2.x of the xAPI specification all timestamps will have to be recorded in UTC, see:
A Timestamp shall be formatted to UTC
(https://gitlab.com/IEEE-SA/xapi/9274.1.1/xapi-base-standard-documentation/-/blob/master/9274.1.1%20xAPI%20Base%20Standard%20for%20Content.md#527-additional-requirements-for-data-types)
So it would likely be better to go ahead and start following that pattern.
If the timezone is relevant for other purposes it would be better to track the timezone itself separately from the timestamp (likely as a result or context extension).
There are two clients with same window application. One is in India and other one is in Belgium. Sql server and web service application is hosted at Belgium. In sql I am storing UTC date time.
Now issue is a time difference for this two clients. I want to show UTC time in history form that mean what is stored in Database I have to bind that data to gird. No any extra code because I suppose to bind UTC date-time. Event then I get time difference for this two client.
Blue header screen is of a Indian client and other one is of a Belgium client. In Belgium time is showing exactly as in Database but difference is for India. Am I missing anything in configuration or what?
You have to convert both time zone in standard UTC and save it. Used dateadd() function to manipulate datetime. such as
declare #IST_date datetime
declare #BE_date datetime
declare #UTC_date datetime
--Indian standard time is (GMT + 5:30 hrs)
-- Belgium standard time is ( GMT + 1 hour)
select #UTC_date = DATEADD(hh,5.30, #IST_date)
select #UTC_date = DATEADD(hh,1, #BE_date)
why not simply convert the value at display ?
DateTime MyDate = Data["ChangedDate"];
DateTime MyDateUTC = MyDate.ToUniversalTime();
tadaaaaa
Ditch System.DateTime and use Noda Time!
Getting Started with Noda Time
System.DateTime uses the system culture and time zone at unpredictable moments, where Noda Time works without any defaults. Takes a bit of work to understand, but you'll never look back.
Use Noda time on the client, and store all the values in UTC in the database. You may also wish to store the original time zone that the date time was entered in.
I usually have an "interceptor" that right before reading/writing from/to the database does DateTime conversion (from UTC to local time, and from local time to UTC), so I can use DateTime.Now (derivations and comparisions) throughout the system without worrying about time zones.
Regarding serialization and moving data between computers, there is no need to bother, as the datetime is always UTC.
Should I continue storing my dates (SQL 2008 - datetime) in UTC format or should I instead store it using DateTimeOffset (SQL 2008 - datetimeoffset)?
UTC Dates in the database (datetime type) have been working and known for so long, why change it? What are the advantages?
I have already looked into articles like this one, but I'm not 100% convinced though. Any thoughts?
There is one huge difference, where you cannot use UTC alone.
If you have a scenario like this
One server and several clients (all geographically in different timezones)
Clients create some data with datetime information
Clients store it all on central server
Then:
datetimeoffset stores Local time of the client and ALSO offset to the UTC time
all clients know UTC time of all data and also a local time in the place where the information originated
But:
UTC datetime stores just UTC datetime, so you do not have information about local time in the client location where data originated
Other clients do not know the local time of the place, where datetime information came from
Other clients can only calculate their local time from the database (using UTC time) not the local time of the client, where the data originated
Simple example is flight ticket reservation system ... Flight ticket should contain 2 times:
- "take off" time (in timezone of "From" city)
- "landing" time (in timezone of "Destination" city)
You are absolutely correct to use UTC for all historical times (i.e. recording events happened). It is always possible to go from UTC to local time but not always the other way about.
When to use local time? Answer this question:
If the government suddenly decide to change daylight savings, would you like this
data to change with it?
Only store local time if the answer is "yes". Obviously that will only be for future dates, and usually only for dates that affect people in some way.
Why store a time zone/offset?
Firstly, if you want to record what the offset was for the user who carried out the action, you would probably be best just doing that, i.e. at login record the location and timezone for that user.
Secondly if you want to convert for display, you need to have a table of all local time offset transitions for that timezone, simply knowing the current offset is not enough, because if you are showing a date/time from six months ago the offset will be different.
A DATETIMEOFFSET gives you the ability to store local time and UTC time in one field.
This allows for very simple and efficient reporting in local or UTC time without the need to process the data for display in any way.
These are the two most common requirements - local time for local reports and UTC time for group reports.
The local time is stored in the DATETIME portion of the DATETIMEOFFSET and the OFFSET from UTC is stored in the OFFSET portion, thus conversion is simple and, since it requires no knowledge of the timezone the data came from, can all be done at database level.
If you don't require times down to milliseconds, e.g. just to minutes or seconds, you can use DATETIMEOFFSET(0). The DATETIMEOFFSET field will then only require 8 bytes of storage - the same as a DATETIME.
Using a DATETIMEOFFSET rather than a UTC DATETIME therefore gives more flexibility, efficiency and simplicity for reporting.
I am building a simple CMS to manage articles.
My MS SQL Server 2008 is Hosted in USA, Author of Data Base are situated in USA and Germany.
When a Author create an article in the DataBase I would like record the DATE of creation.
I would like to show the date on the website as would all contents and articles are created from Germany.
My questions:
A) - shell I use SYSDATETIMEOFFSET() as DEFAULT in DataBase and in the Business Logic Layer converted to Germany time?
B) - shall I add DATE from the Business Logic Layer directly without letting the DataBase adding the datetime, and showing the data as it is?.
I hope my question is clear.
If you are able to send me some link-resource I would appreciate it
Thanks guys :-)
Store dates in UTC with the timezone offset, use this date inside the application as well.
Only convert to the local time display in the last moment.
Best practices for datetime, daylight saving and timezones are collected in this question.
My recommendation would be to go with UTC - this way you have an absolute frame of reference.
This is done in SQL Server using
select getutcdate()
Store dates in some standard time in your DB, regardless of time zone it originated from.
Store/calculate time zone of user, and whenever you display the data to the user, convert it to the user's timezone in the BL/Presentation Layer. Don't do it in the UI, you'll end up with pain later!
I am developing reports using Microsoft SQL Report Builder 2.0. One of my requirement is to display the timezone information by passing "Timezone Offset" (-08:00) as a parameter to the report. Based on the offset value, we convert a UTC date to its appropriate timezone value (using VB.NET) and display the same. However, this does not consider the daylight savings. Is there anyway to incorporate daylight savings related changes to our conversion?
FYI, the platform is .NET Framework 3.
Thanks,
Veera
Take a look at the following:
TimeZone.GetDaylightChanges
DaylightTime
TimeZoneInfo
There are all sorts of properties and methods that you may be able to take advantage of.
I got the answer, If I want to acce.ss the timezone in the code. I need to add the "system.core" & then if imezonecreate a timezoninfo object and I can create custom timezone. Also we can get all timezones available zones from the system.
http://msdn.microsoft.com/en-us/library/system.timezoneinfo_members(v=VS.100).aspx
http://msdn.microsoft.com/en-us/library/bb309898(v=VS.100).aspx