The older version of date format is dd-mon-yy. In that case yy represents year. But if we write 31-aug-14 in oracle 10g the full date format is 31-aug-1914.
The newer version of date is dd-mon-rr. So in that date format what does rr represent? I know that it represents 21st century but what does rr mean? Please I want to know. I asked my faculties but they also don't know.
RR means the programmer was too lazy (or ignorant) to use YYYY. Seriously.
The RR mask was introduced in the late nineties as a kludge for the Y2K problem. It was intended to help database programmers finagle input data, because changing screens was a lot more labour intensive. It substitutes a default century of a date entered without one. YY just substitutes the current century. However, in the last years of the last century that would often not be what was intended: in 1999 it was more likely that a two-digit year like 01 would be two years in the future (i.e. 2001) rather than ninety-eight years in the past (1901).
This background is important: it explains why RR pivots around 2000. So, RR prepends 50-99 with 19 and 00-49 with 20. Consequently RR will increasingly often default to the wrong century. It was only supposed to be a stopgap for legacy code: there is no excuse for using it in new applications.
To quote the Oracle documentation:
The RR datetime format element is similar to the YY datetime format element, but it provides additional flexibility for storing date values in other centuries. The RR datetime format element lets you store 20th century dates in the 21st century by specifying only the last two digits of the year.
Source: http://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements004.htm#SQLRF00215
So basically it allows you to only specify 2 numbers of the year and Oracle will handle the century for you. In the documentation, you will also find the logic behind this. Another use is the use in queries:
The RR datetime format element lets you write SQL statements that will return the same values from years whose first two digits are different.
Related
Trying to convert a datetime format column (example value: 12-11-2020 18:15:06) which is actually a nvarchar into this date format: yyyymmdd
This is what I tried so far but I'm getting the following error:
What am I doing wrong?
There are many problems here.
Dates should not be stored as strings.
You lose the ability to perform any kind of date math or extract date parts.
You lose built-in validation (both invalid dates like February 31st and any garbage that doesn't even look like a date).
For example, we have no idea if 12-11-2020 is December 11th or November 12th, or if the data was entered consistently. Imagine a person from the US did some of the data entry and a colleague from Germany did the rest.
FORMAT() is the most expensive way to format a date (see this and this - these are articles about removing time altogether, but the overhead with FORMAT() is the same).
An index on MYDATE can't be used to satisfy this query, so you will do a full table scan every time, which will get worse and worse as the table grows.
You can perform your query in your given scenario without changing anything, but I highly recommend you fix the column and make sure data entry can't be arbitrary (use a date picker or calendar control so you dictate a consistent format).
If 12-11-2020 is December 11th:
WHERE TRY_CONVERT(date, MYDATE, 110) >= #DateVariable;
If 12-11-2020 is November 12th:
WHERE TRY_CONVERT(date, MYDATE, 105) >= #DateVariable;
Note that this still might not get the correct and logical results if some people thought they entered December 11th and others thought they entered November 12th.
You can see all the valid style numbers for CONVERT/TRY_CONVERT here.
I realise that you can use SET DATEFORMAT to alter the way that a string is parsed but is the following unambiguous:
SELECT CONVERT(DATE, '02Oct15')
Is there any circumstances that this would be interpreted as 15th October 2002?
The century conversion will be an issue in 35 years (the y2k50, there is an amusing thought), but until then it's unambiguous. Any attempt to pass an invalid date in the first section results in a conversion error rather than it treating the third section as a date instead of a year.
Finally changing the default language (which changes the default date format) uses the same conversion (British), or causes it error out (Italian). Still as others have mentioned, storing dates in this format is a bad idea, however unless I miss my guess this seems like your importing data from a report, so you probably don't have much control over it. Anyway hope that helps and good luck.
I was not able to make 02Oct15 to become October 15, 2002. However, if all three date components are numbers, it's easy to make that cast:
SET DATEFORMAT YMD
SELECT CONVERT(DATE, '02Oct15'), -- October 2, 2015
CONVERT(DATE, '021015') -- October 15, 2002
I suspect that once you introduce natural language to the string, SQL Server use culture-specific rules to convert the date components. But in the end, only Microsoft knows what SQL Server's string-to-date algorithm is.
In Excel 2010 VBA, I'm testing to make sure my code handles invalid user input correctly. I'm using CDate to validate date inputs. I've found that with the invalid date input "0/5/14", CDate returns the date 5/14/2000.
Is that a CDate bug, or am I missing something? In an Excel worksheet cell, "0/5/14" does not evaluate to a date.
Similarly, Year("0/5/14") in Excel VBA returns 2000, while =Year("0/5/14") in an Excel worksheet cell returns an error.
Windows regional settings are English USA, so month/day/year is standard.
The CDate function (and other string-to-date functions such as DateValue) examines a string representation of a date and attempts to match it to any known date format, considering it to be a valid date unless it cannot be made to match any of the known formats. Since it can be the case that years can be expressed as 1 or more digits, the input string "0/5/14" can be considered to be in year/month/day format, so it returns "14th of May, 2000" in your local date format.
The difference between CDate and DateValue is that CDate can accept a number, while DateValue cannot. Both use the PC's Short Date format first - not that that would matter for someone using en-US settings. Both functions fall back to other date formats if the supplied string doesn't fit on the first attempt.
It is up to you how you handle such situations. It may well be that in your situation, a date in year 2000 would be out-of-range, so you could reject it on that basis. If you want to insist on "mm/dd/yyyy" format, you could write your own parser code.
I believe #Borja Güiles Quintana had the correct answer with basically it's reading it as YY/MM/DD. CDate does not exist as a worksheet function so it does not surprise me that the sheet (as opposed to VBA) interpretation differs (would not be the first time, eg TRIM).
Any year (and which part represents year may be system dependent) is interpreted according to rules (that may be version dependent) but for Excel 2013 and two-digit values these stop at 29 for this century - ie 30 is interpreted as 19 30. More details of that here.
I have a date in the format [last two year][day of 365]. Using either SQL or excel functions, I need to determine the date this pertains to. The year is always the last two of the 2000s. There are no dates from before 2007. Is there a way to easily do this? I'm using this for a quick check, and am trying to avoid a large coding time for this.
In SQL, the date-handling functions seem to vary widely by SQL vendor, and there don't seem to be any good standard ways of handling date offsets. However, if you were a bit more specific about the specific SQL server you're using, someone might be able to provide an answer that applies.
In Excel, you can build a date for the first day of the year (e.g. 2008-01-01) and then add the number of days numerically, subtracting 1 so that the first day is still 2008-01-01; the resulting value, when formatted as a date, should be the precise date value. For example, =DATE(2008,1,1)-1+320 returns a date of 11/15/08 (at least in LibreOffice Calc).
You can try this formula in Excel where your data is in A1
=DATE(LEFT(A1,2)+100,1,RIGHT(A1,3))
I have 2 fields in the database month (numeric) and year (numeric) and I want to combine them in a report that combines those 2 fields and format them with MMM-YYYY. e.g 7-2008 becomes Jul-2008. How do I do that?
DateSerial is the correct answer:
http://msdn.microsoft.com/en-us/library/bbx05d0c(VS.80).aspx
SSRS uses VB.Net for expressions. Use the expression editor to browse the available functions, one of which is DateSerial.
To format the date, set the Format property on the textbox. You should be able to use "MMM-yyyy" as the format.
Update: As Peter points out, you would specify the parameters as needed. If you just care about year and month, just supply a value of 1 for the day. Since you are formatting the value without the day component it really doesn't matter what value you use (as long as it creates a valid date).
=DateSerial(year, month, day)
Brannon's answer is correct except that he omits the fact that you merely specify a literal for the day. Any value between 1 and 28 will do.