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.
Related
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.
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 );
Does hibernate have any mapping for this oracle data type:(10G)
TIMESTAMP(6) WITH TIME ZONE
I am getting:
No Dialect mapping for JDBC type: -101
My manager does not want to do the: registerHibernateType(-101, Hibernate.getText().getname())
He thinks it is too much.:)
What alternative can I have?
The answer you provide to yourself is more like a workaround than a proper solution. For the sake of the visitors looking for an answer, I'll provide my view on this:
1) Database date-based fields should be always set to UTC, never with a specific timezone. Date calculation with timezone information is an unneeded complexity. Remember that timezones usually changes twice a year for a lot of countries in the world ("daylight saving time"). There's a reason why only a few RDMBS' supports this, and there's a reason why Hibernate developers refuse to support this data-type. The patch for Hibernate is simple enough (one line of code), the implications aren't.
2) Converting your "timestamp with timezone" to a String will only cause problems later. Once you retrieve it as String, you'll need to convert it again to a Date/Calendar object, an unneeded overhead. Not to mention the risks associated with this operation.
3) If you need to know in which timezone is some user, just store the String representing the timezone offset (like "Europe/Prague"). You can use this in Java to build a Calendar with date/time and timezone, as it'll take care of DST for you.
For now, I solved the problem by:
`select TO_CHAR(TRUNC(field)) from table` //field is the one having type= timestamp with timezone
This ensures that when the query returns, the field has datatype 'String'
We have an NHibernate app that we are migrating from SQL Server to Oracle. Our optimistic concurrency is implemented via a <timestamp name="Version"> mapping element.
The data type of the corresponding Version column in Oracle is DATE. After we save an object, the in-memory C# object is left with a timestamp value in milliseconds (e.g. 12:34:56.789) while the value in the database is precise only to the second (e.g. 12:34:56). Thus, if we attempt to save the object a 2nd time, we get a StaleStateException because the two values do not match.
I attempted to fix this by altering the data type of the Version column to TIMESTAMP(3). Unfortunately, the C# object and the DB value are still off by one millisecond (e.g. 12:34:56.789 vs 12:34:56.788), so the 2nd attempt to save the object still causes a StaleStateException.
What can I do to create a working <timestamp> mapping to an Oracle column of type DATE or TIMESTAMP so that the same object can be saved multiple times?
Thanks.
-- Brian
TIMESTAMP(7) has the correct precision to match the .NET DateTime class and fixed the problem.
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.