Is it possible to map a .Net DateTime to a TIMESTAMP with TIMEZONE type in Oracle using NHibernate? Looks like it's not readily available in "Hibernate"
If this is not available out of the box, can someone please direct to examples of how it may be achieved.
We were not able to find a proper mapping to this using NHb 3.1. However extended support for times (including timezone etc...) is available for SQL Server '07 onwards.
Our solution was to use a varchar field instead of timestamp and format the dates to include the timezone information. The consumer of this data was able to handle this change accordingly.
You could also convert them to UTC and store that.
Related
Dates in database(SQL) are in UTC. I want to get the dates based on the Timezone.
Say for example if it's IST (UTC+05:30) then I want to get the IST date and time in database. If anyone knows, please guide me to do operation in database (I have date and offset of the particular timezone).
You've tagged as SQL Server 2008 so you will be able to use DATETIMEOFFSET.
No easy & generic method exists if you want to be able to display dates from the past or future. The problem is that you have to take DST at the date into account.
The easiest way is to add a .Net assembly to your database to manage this.
I have data stored on a SQL Server in a country that is GMT + 2. So for instance, a DateTime value is something like 1/1/1800 12:00:00 AM.
Now, I have a C# console app, that is running on a server in UK. The C# is reading those values from the remote database. However, the date received are 2 hours less, for instance: 31/12/1799 22:00:00.
I changed culture to en-US, the only thing that changed was the printing of 10:00:00 PM instead of 22:00:00
Any idea why the date values are being "auto-converted" to locale timezone instead of keeping the values as is?
Thank you
Regards
The problem you're experiencing is not related to the culture on your computer, it is related to a conversion of timezones.
When initializing the connection - there's a negotiation happening between you and the server that tells the server the time zone of your location, and does the conversion for the communication automatically for you.
First, try to understand what is stored in the DBMS, and what you want it to store.
Maybe you need to change your DateTime type to one that considers timezones: for example: http://blogs.msdn.com/b/sqlprogrammability/archive/2008/03/18/using-time-zone-data-in-sql-server-2008.aspx
If you don't want to have timezone "adjustments" try to synchronize the DBMS session to be on the same timezone (between your client and the SQL Server) - so no conversions would occur.
There are two things you shouldn't confuse here: (1) how the data is stored in the database; (2) how it is displayed. The database should be storing the information in a timezone-agnostic way; it's up to you how you display it.
This means that there are two things that might be going wrong. Either it's being stored wrong, because the application putting things into the database is not correctly interpreting the date/time that it wants to store, or, more likely, you're converting to local time when you display it.
I'm not sure how you're doing the conversion, but lots of date/time functions will use the default locale if you don't specify one. They will allow you to specify a locale if you want to, though.
If I were you, I'd have a look at the raw data in the database to see whether that's correct.
In Oracle DATE output format is set using NLS_DATE_FORMAT but in PostgreSQL it is not flexible to set the DATE output format like Oracle.
In PostgreSQL DATE output format can be set using DateStyle but DateStyle values are limited so user can not change the DATE output format flexibly.
To overcome this problem we can use to_char().
Is there any other way to set DateStyle or Create custom DateStyle output format?
You've already shown the options:
to_char; or
DateStyle, within the limits it allows.
Client applications are supposed to format dates. PostgreSQL just supplies a standard date in an easily parsed format for client drivers to read. In fact, if you use the binary protocol it just sends the date as a bigint.
If you feel strongly about this you could propose a patch to the pgsql-hackers mailing list adding the feature you desire. You will need to be willing to learn enough PostgreSQL back-end coding to implement this yourself, or to pay someone else to do it. I don't particularly see why DateStyle couldn't be extended to accept a format string, but I don't think anybody's cared enough to do the work (and patch all the client drivers to support it).
I have timestamp type data in sql-server. I wonder what should be related data type in vb?
Should it be string,date,Byte or something else?
sql-server TIMESTAMP is not a DATE data type. It is used for row versioning and usually referred to as ROWVERSION Documenation here
with that being said, sql-server treats it as binary. So I'm not sure what value it will give you in application, but if you needed to convert it to VB the closest you can get is making it a string. VB data types documentation here
here is example of TIMESTAMP from sql-server-2012
0x000000002AB82831
0x000000002AB8280D
0x000000002AB827C4
0x000000002AB82710
0x000000002AB82758
0x000000002AB82759
0x000000002AB82832
0x000000002AB8277C
Does SQLs built-in DateTime type has any merits over nvarchar type?
If it were you , which one would you use?
I need to store dates in my SQLServer database and I'm curious to know which one is better and why it is better.
I also want to know what happens if I for example store dates as string literals (I mean nvarchar )? Does it take longer to be searched? Or they are the same in terms of performance ?
And for the last question. How can I send a date from my c# application to the sql field of tye DateTime? Is it any different from the c#s DateTime ?
You're given a date datetype for a reason, why would you not use it?
What happens when you store "3/2/2012" in a text field? Is it March 2nd? Is it February 3rd?
Store the date in a date or datetime field, and do any formatting of the date after the fact.
EDIT
If you have to store dates like 1391/7/1, your choices are:
Assuming you're using SQL Server 2008 or greater, use the datetime2 data type; it allows dates earlier than 1753/01/01 (which is what datetime stops at).
Assuming you're using SQL Server 2005 or earlier, store the dates as Roman calendar dates, and then in your application, use date/time functions to convert the date and time to the Farsi calendar.
Use the correct datatype (date/datetime/datetime2 dependant on version and requirement for time component).
Advantages are more compact storage than storing as a string (especially nvarchar as this is double byte). Built in validation against invalid dates such as 30 February. Sorts correctly. Avoids the need to cast it back to the correct datatype anyway when using date functions on it.
If I'm storing a DateTime value, and I expect to perform date-based calculcations based on it, I'll use a DateTime.
Storing Dates as strings (varchars) introduces a variety of logistical issues, not the least of which is rendering the date in a proper format. Again, that bows in favor of DateTime.
I would go with the DateTime since you can use various functions on it directly.
string wouldn't be too much of a hassle but you will have to cast the data each time you want to do something with it.
There is no real performance variance while searching on both type of fields so going with DateTime is better than strings when working with date values.
you must realise the datetime datatype like other datatypes is provided for a reason and you should use the datatype that represents your data clearly.. Besides this you gain all the functionalities/operations that are special to the datetime datatype..
One of the biggest gains is correct sorting of data which will not be possible directly if you use nvarchar as your datatype.. Even if you think you dont need sorting right now there will be a time in the future where this will be useful.
Also date validation is something that you will benefit from. There is no confusion of the dateformat stored i.e dd/mm or mm/dd etc..
There is lot discussed about the subject. There is good post on the SQLCentral forum about this particular subject DateTime or nvarchar.
In short, nvarchar is twice as longer as datetime, so it takes more space and on the long range, any action affecting it will be slower. You will have some validation issues and many more.