We have a reporting application where all DateTimes are stored in UTC in the database (SQL server 2005)
The reporting application works simply be retrieving a DataTable and binding to a DataGrid displaying the information.
If we know the logged in users time zone (e.g. +3 GMT), is there any way to update the DataTables dates which are in UTC to now display in the users time zone?
We know we can spool thorugh each column/row in the DataTable and do a conversion but is there a better more efficient way?
I would modify the time as it is displayed to the user. Keep how it is stored consistent, but also store what their timezone is, and then modify the UI to show the correct local time. For example, if their time zone is Central Standard Time, then you could use something similar to the following code:
SomeDataObject someDataObject = new SomeDataObject();
someDataObject.TimeZone = -5; //UTC Timezone for Central Standard Time
someDataObject.Time = DateTime.Now;
DateTime someTime = someDataObject.Time;
someTime.Add(someDataObject.TimeZone); // Display this back to the user
If using .NET, there's a built in class that was made precisely for this purpose. TimeZoneInfo (http://msdn.microsoft.com/en-us/library/system.timezoneinfo.aspx) as taken from the article:
A TimeZoneInfo object can represent any time zone, and methods of the TimeZoneInfo class can be used to convert the time in one time zone to the corresponding time in any other time zone. The members of the TimeZoneInfo class support the following operations:
Retrieving a time zone that is already defined by the operating system.
Enumerating the time zones that are available on a system.
Converting times between different time zones.
Creating a new time zone that is not already defined by the operating system.
Serializing a time zone for later retrieval.
Hope this helps.
Related
I am currently building an out of office workflow in Microsoft powerautomate for Teams. When a request for 8/19/20 gets submitted it gets changed to 8/20/20 and same thing with the end date. Is there a way to set a it so it shows the actual dates selected?
So i think this is happening due to Default UTC time zone is used by Power Automate. Here is a flow that uses the Convert time zone action with a base time of utcNow(). Convert the time to needed timezone and then used an Update item action to update a date field with that converted time value. The correct time shows up in my SharePoint list
Hope this may help you.
I saved a record in 17:16:15, I run a job which gets the ModifiedOn field of my record and I got- 15:16:15, my GMT is +2, I want to know how to fix that gap that my result will turn out like it should be - 17:16:15. I can't select it from DB I need a solution in server side (c# I mean) what can U do in that case?
DateTimes are always saved in UTC in the database. *
You need to dynamically convert from UTC into your local time zone. In C#, you can do this with the .ToLocalTime() method as long as your code is running in the correct time zone. You can also find your local time in the FormattedValues collection of the response, which uses your Dynamics timezone user settings . But the raw datetime value in the database will always be in UTC.
* The only exception to this is if the DateTime field is set to “TimeZone Independent” in the attribute type settings. But be careful: once you set this option you can’t change it for that field again.
A lot of questions have been asked about this subject. The best answer that I found is this one: How to set local timezone in laravel
So the main rule is to keep all database entries in the same timezone.
But I have a specific case where this answer does not work for me. For some models, I have only a date (no datestamp). Example: suppose that I only store the date of when this question was asked (= 2018-01-25). However in Europe it is already 2018-01-26. Someone has a solution for this?
Changing my date field to a datestamp? What with existing dates?
You can use this library jamesmills/laravel-timezone
OR
If you need custom configuration:
Configure your app timezone to UTC.
'timezone' => 'UTC',
You can store different timezones in database column.
When outputting/displaying dates, just format it to use that timezone.
$timezone = 'America/Vancouver';
$model->created_at->setTimezone($timezone);
created_at and updated_at are automatically converted to carbon instances, which makes this easier. If you have other dates that you're using, add them to the protected $dates array on the model and laravel will convert them to carbon instance too. Then you can use carbons setTimezone() to change the date/time to the timezone.
If you're only talking about a date, then there is no time component and thus time zones are irrelevant. For this reason, most platforms do not have a separate date-with-zone type.
You're correct that not every time zone experiences the same date at all times, and that the start of a date and the end of the date occur at different times in different time zones. However, did you notice that in the prior sentence that I had to use the word "time" to rationalize about these points? :-)
Because date and time zone don't come together without time, there's no purpose in keeping them in the same field. Instead, keep two fields in your model - one for the date, and one for the time zone. In many cases, you may even find they belong in two different models.
As a use case example, consider birthdays. Mine is 1976-08-27. That's all it is - just a date. The time zone of my birth is irrelevant, and so is the time zone I'm located in - until I want to evaluate whether it's currently my birthday (or how long until my birthday, etc.) For those operations, my current time zone is important, and so is the start time-of-day and end time-of-day of that time zone. Thus - two different fields.
I am currently storing events of some entities in UTC time but I am not sure if I should do that in this case. Imagine there's an event at 10pm local time (-4h UTC) and a mobile App fetches "todays events". This could e.g. look like this:
App sends request to fetch all clubs in the near location
After receiving all clubs it sends a request to get all events for today. It therefore sends the local time Sun. 10pm to the server.
The server would convert the local time of the mobile device to UTC Mon. 1am and fetch all events from Monday. But of course that was not what I wanted.
Fetching all events from the clubs and convert them to their local time using their local time offset information is not really a great solution.
So wouldn't it be better to just store all events in local time? In that case the mobile App would send its local time to the server which would be able to query all events from the clubs in local time as well.
This sounds much simpler to me but I am not sure if I overlook something.
So what would I do in this case?
Yes, storing everything in UTC is probably the best solution.
You don't say how you are "storing" the dates/times, but if you are using Dates or Joda equivalents, then you should know that their underlying representation is effectively in UTC (they represent a moment in time as an offset in milliseconds since the "Epoch", which is Midnight, Jan 1, 1970 UTC). These dates only have a timezone when you format them as Strings.
Most databases do something similar (store the date in a common timezone, usually UTC). The major exception that I've found is the generally available date-time related column types in MS SqlServer which by default store everything in the local timezone of the server.
Also be aware that if you use SQLite, and you store a date/time by passing a String in SQL that contains a timezone, SQLite will store it without warning, but will ignore the timezone and assume that the timezone is UTC, giving you a result other than what you might expect.
For more on this, see my (old) blog post at http://greybeardedgeek.net/2012/11/24/java-dates/
The other answer is correct. Some more thoughts here.
A time zone is more than the offset from UTC mentioned in the Question. A time zone is also the set of past, present, and future rules for anomalies such as Daylight Saving Time. You should refer to a time zone by its proper name, continent plus Slash plus city or region. Never use the 3-4 letter codes such as EST or IST.
To search for events in the user's "today", you must know the user’s time zone. For example, a new day dawns earlier in Paris than in Montréal. After the stroke of midnight in Paris we still have a few hours of “yesterday” left to go in Montréal.
While you can make a guess as to the user’s time zone, the most reliable way is to ask the user.
DateTimeZone zone = DateTimeZone.forID( "America/Montreal" );
DateTimeZone now = DateTimeZone.now( zone );
DateTime today = now.withTimeAtStartOfDay();
DateTime tomorrow = today.plusDays( 1 );
// Search for events that start >= today AND that start < tomorrow.
To search Joda-Time objects, use the Comparator built into DateTime. That comparator works across objects of various time zones.
To query a database, convert that pair of DateTime objects into java.sql.Timestamp objects. You do that by extracting and passing the count of milliseconds since the epoch of 1970 in UTC.
long m = today.getMillis();
java.sql.Timestamp tsToday = new java.sql.Timestamp( m );
My Linq query of DateTimeOffset column always throws InvalidTimeZoneException. The data appears to be correct. Any idea what's happening?
Details:
Oracle Column: CREATED_DATETIME TIMESTAMP(0) WITH TIME ZONE
EF MAPPING: public Nullable<System.DateTimeOffset> CREATED_DATETIME { get; set; }
DataAccess: ODP.net Oracle.DataAccess
Data Sample: (Timezone column available but not used)
CREATED_DATETIME TIMEZONE_NAME
8/16/2013 5:06:05 PM +00:00 US/Central
8/16/2013 5:35:06 PM +00:00 US/Mountain
Code:
var q = from isr in pc.ISRs
select isr.CREATED_DATETIME;
try
{
DateTimeOffset? value = q.First();
}
catch (InvalidTimeZoneException tze)
{
throw new ApplicationException(tze.Message);
}
catch (Exception e)
{
throw new ApplicationException(e.Message);
}
var orders = from o in q select o;
Oracle's TIMESTAMP WITH TIME ZONE type, (aka TIMESTAMPTZ) is a funny creature. It stores a date, a time, and either a fixed "time zone offset" or a "time zone region name".
When there's a fixed offset, then the DateTimeOffset type in .Net would be a good match, and it is not surprising that Entity Framework is using that as the default. (Although technically, the mapping probably comes from the underlying ODP.net provider rather than from EF.)
But when it's a time zone region name, there are going to be issues:
Those time zone names are IANA time zones, and aren't usable directly with the TimeZoneInfo class. They would need to be translated. See the section on time zone databases in the timezone tag wiki.
.NET doesn't have any type that represents a DateTime or DateTimeOffset paired with a time zone.
The Oracle data doesn't actually include the time zone name. Instead, it includes a pointer back to an id in the system data within the Oracle database. So any resolution of this name from the raw bits would have to be done while a connection to the database was still open. Not to long ago, I answered a question about this and how it relates to Java. You can read my response here, which mostly applies still for .NET. (Although I'm sure the implementation is quite different in ODP.net.)
It's worth pointing out that the Noda Time library includes both IANA time zone data, and the ZonedDateTime type, which could fully represent an Oracle TIMESTAMPTZ. There is no direct mapping, but I suppose it should be possible to construct a ZonedDateTime when calling your Oracle database.
However, there is currently no support for Noda Time with Entity Framework, so that would get in the way here. (That is on my agenda, but I have not looked into it very deeply yet.)
So most likely, the only way you will be able to use the TIMESTAMPTZ type within Entity Framework is to make sure you are using fixed offset zones only. Using it with an Oracle "time zone region name" is not going to work. At least - not yet.
It's a shame really. The region names are a nice feature, because then you are automatically getting the benefit of daylight saving time changes being incorporated into the calculation.