In my current solution, I am converting a DateTime value, "Time" in my database using CONVERT so it displays in a ##:##AM/PM format, and I realize that CONVERT just takes whatever datatype and turns it into a VarChar, or a String once its in C#. This is making my sort work incorrectly in my Gridview. I am sorting the columns in my DataSet returned from my stored procedure. However it isnt sorting by AM/PM since its a string literal, and not a DateTime.
What is the best way to sort Time values? Should I use a different datatype, like TIME in my database? Different CONVERT command? I'm stumped! I can't use a 24 hour format, that's the only restriction. Thanks!
A couple of thoughts:
Could you use AM 01:23 / PM 01:23 format - this would sort well.
If you can return the times from the database in DATETIME format, but with the date set to some 'constant date' (e.g. 2000-01-01 hh:mm), you could almost certainly put a format string on the GridView column to display just the time, whilst still enabling sorting by the underlying value.
I use ticks: http://www.codeproject.com/KB/database/DateTimeToTicks.aspx
Or (if possible) DateTime - and handle it in my grid.
You can add an additional column with the date/converted date which is hidden in you gui but used to sort.
Related
I have a wrong date in the database 2022-10-14 12:59:00 , I want to change it to 2022-14-10 12:59:00. Is there a direct convert function I could use, or do I have to split and put the date correctly. Just trying to get some ideas to do this the easy way. I tried the convert functions but I guess the original date as to be corrected first is it?
You can use the CONVERT() function to go from a date type to a string with a particular "style". There are styles for different presentation formats to represent the different date presentation formats around the world.
To make this work, the data needs to be in a date type, not just a string. (or you can convert from a string type to a date type, then convert back to a string).
Date style descriptions
I have read-only access to data where time is stored as time object (date is irrelevant). I need to subtract a few seconds from each row. So the simplest way I know is to use timedelta, but first, I need to convert time column to datetime column. There should be a straight-forward way to do that; apparently there is not.
Ok, finally I found a solution that was obscured by many wired workarounds. It required format argument: pd.to_datetime(measures.time,format='%H:%M:%S'), where format must be exactly the same as time is formatted.
A one-line solution if anybody will come with similar question:
time = (pd.to_datetime(measures.time,format='%H:%M:%S') - delta).dt.time
where measures is a dataset and time is column name
I have a view in SQL Server 2012 and there is a column of containing dates×. I have been trying to convert the date column as '20/10/2018 18:00' format (no second) by using this feature and lots of approaches on Stackoverflow and other web sites:
FORMAT(StartDate, 'dd.mm.yyyy hh:mm')
However, as the data type of this column is Varchar (String) rather than DateTime, I encountered some problems in C# side and I want to perform this conversion on the database side without changing the data type of the generated format). Is there any way to achieve this?
SQL Server doesn't have a "date format" per se. The formatting of datetime fields is only performed when presenting the datetime to an output - that is, when converting it to a string.
There is a default format for presentation that is controlled by the server's collation setting. However, internally the date is stored as a numeric value (actual format varies by type, as datetime and datetime2 have different internal formats), and that value has no associated formatting.
You can store your date without seconds by using a smalldatetime field, or by manipulating the input data to trim off the seconds value. But, unless you store your date as a string, which is absolutely not recommended, you will not be able to save an output format different from the default collation-driven format in a datetime field.
I would migrate that column to a datetime (or some variant) if possible. Alternatively if that would affect too many things, you could make a computed column on the table which converts the string date you have to a datetime. That way the database doesn't have to care about the formatting at all; it just works with the proper DateTime data type.
If neither of those is an option, you can just pas the string to C# and use DateTime.TryParse() to convert it to a C# DateTime object.
In either case, it's preferable to work with the date as a DateTime up until the very last minute where you need to format it for display somewhere.
I have a variable "month" in SQL DB with 2 different formats: yyyy-mm and yyyy-m (e.g., 2015-11, 2016-1). When I try to sort the 'month" (ascending or descending), it is not showing properly due to this format difference. How to change the yyyy-m format to yyyy-mm?
If you can be certain that it's never going to be anything other than those exact formats you can insert a zero at a known point in the string -
SELECT MonthField,
CASE WHEN LEN(MonthField)=6 THEN
LEFT(MonthField,5)+'0' + RIGHT(MonthField,1)
ELSE MonthField
END AS MonthField_Cleaned
FROM SourceTable
But if at all possible you'd be better off cleaning whatever's creating the data, and ideally storing the data as actual dates rather than strings representing the months to ensure they can't get mixed up and you can use the DBMS' date manipulation functions.
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.