March 13, 2013 at 8:39 pm
Comments posted to this topic are about the item Precision required
David Bridge
David Bridge Technology Limited
www.davidbridgetechnology.com
March 13, 2013 at 10:30 pm
an easy one for the day !!!
thanks for the question
~ demonfox
___________________________________________________________________
Wondering what I would do next , when I am done with this one :ermm:
March 13, 2013 at 10:47 pm
demonfox (3/13/2013)
an easy one for the day !!!thanks for the question
+1
Thanks David!
~ Lokesh Vij
Link to my Blog Post --> www.SQLPathy.com[/url]
Follow me @Twitter
March 13, 2013 at 11:10 pm
easy +1 🙂
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
March 13, 2013 at 11:50 pm
I thought smalldatetime will round off to next day only if there is 2 seconds difference and answered both will return day as 24.
--
Dineshbabu
Desire to learn new things..
March 14, 2013 at 12:22 am
Lokesh Vij (3/13/2013)
demonfox (3/13/2013)
an easy one for the day !!!thanks for the question
+1
Thanks David!
+2
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
March 14, 2013 at 1:08 am
Thanks David Bridge for good and interesting question. 🙂
Thanks
Vinay Kumar
-----------------------------------------------------------------
Keep Learning - Keep Growing !!!
March 14, 2013 at 3:08 am
Most disappointing. I was sure when I got to the thread I'd see several pages of identical replies saying that it gives an error about assigning variables in the declare statement. What is the world coming to?!
March 14, 2013 at 4:09 am
This was removed by the editor as SPAM
March 14, 2013 at 4:21 am
Interestingly, if I run the code, I get:
Msg 242, Level 16, State 3, Line 1
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
But if I change the first line to DECLARE @Datetime datetime = '2013-02-24T23:59:30'
then it works as expected.
What do I have that is different (I'm in the UK if that helps)?
March 14, 2013 at 4:32 am
Richard Warr (3/14/2013)
What do I have that is different (I'm in the UK if that helps)?
Locale settings.
Contrary to popular belief, yyyy-mm-dd hh:mm:ss and yyyy-mm-dd are NOT a guaranteed safe date format. This can, in some locales, still be interpreted as yyyy-dd-mm.
The only guaranteed safe formats for datetime are:
* yyyymmdd for date only; no seperators.
* yyyy-mm-ddThh:mm:ss or yyyy-mm-ddThh:mm:ss.ttt (where ttt is thousands of a second) for date and time; the dashes, uppercase T, colons (and dot in the second version) are all required seperators.
For the date data type, rules have changed slightly. I know both yyyy-mm-dd and yyyymmdd are guaranteed for date. I don't know if there are more changes.
March 14, 2013 at 5:02 am
Thanks for the question. I need review with date types.
March 14, 2013 at 6:08 am
Hugo Kornelis (3/14/2013)
Richard Warr (3/14/2013)
What do I have that is different (I'm in the UK if that helps)?Locale settings.
Contrary to popular belief, yyyy-mm-dd hh:mm:ss and yyyy-mm-dd are NOT a guaranteed safe date format. This can, in some locales, still be interpreted as yyyy-dd-mm.
The only guaranteed safe formats for datetime are:
* yyyymmdd for date only; no seperators.
* yyyy-mm-ddThh:mm:ss or yyyy-mm-ddThh:mm:ss.ttt (where ttt is thousands of a second) for date and time; the dashes, uppercase T, colons (and dot in the second version) are all required seperators.
For the date data type, rules have changed slightly. I know both yyyy-mm-dd and yyyymmdd are guaranteed for date. I don't know if there are more changes.
Thank you Hugo. Pleased to say that I always use the "T" format (which I believe to be ISO) and encourage colleagues to do the same!
March 14, 2013 at 6:10 am
Richard Warr (3/14/2013)
Hugo Kornelis (3/14/2013)
Richard Warr (3/14/2013)
What do I have that is different (I'm in the UK if that helps)?Locale settings.
Contrary to popular belief, yyyy-mm-dd hh:mm:ss and yyyy-mm-dd are NOT a guaranteed safe date format. This can, in some locales, still be interpreted as yyyy-dd-mm.
The only guaranteed safe formats for datetime are:
* yyyymmdd for date only; no seperators.
* yyyy-mm-ddThh:mm:ss or yyyy-mm-ddThh:mm:ss.ttt (where ttt is thousands of a second) for date and time; the dashes, uppercase T, colons (and dot in the second version) are all required seperators.
For the date data type, rules have changed slightly. I know both yyyy-mm-dd and yyyymmdd are guaranteed for date. I don't know if there are more changes.
Thank you Hugo. Pleased to say that I always use the "T" format (which I believe to be ISO) and encourage colleagues to do the same!
I have never used this 'T' format :w00t:
_______________________________________________________________
To get quick answer follow this link:
http://www.sqlservercentral.com/articles/Best+Practices/61537/
March 14, 2013 at 6:40 am
I have never used this 'T' format :w00t:
I need a review on SQL Server format.
--------------------------------------------------------------------------------------
Hai Ton
My Db4Breakfast blog.
Viewing 15 posts - 1 through 15 (of 35 total)
You must be logged in to reply to this topic. Login to reply