I'm in the process of migrating our Data Warehouse from Oracle to SQL Server 2012.
One piece of code I use a hundred times a day in Oracle is changing the date format for a query by using something like:
To_Char(entry_date,'WMMYY') = 30612
The above allows me to grab the date (default format = DD-MON-YY eg 01-JAN-12) and change the format for the week specified (the third week of June in the above example) by simply listing the week desired.
In my mind the above is very simple and easy to use. I can change it to whatever format I want (MMYY, MMYYYY) etc. without any issues. So far I cannot figure out an easy way to do this in SQL Server 2012 and it's really starting to bother me. It's datetime2 in SQL Server.
I'm finding stuff for CAST(), CONVERT(), DATEPART() but from what I've seen there is all kinds of wacky coding and number codes (like 101, 102, I don't understand why this is) required which just seems extraneous and over complicated to me.
Have I just not found what I'm looking for yet or is this just the way it is with SQL Server? I just want to be able to do something simple like grab all the data that was entered in during the month of june or the second week of october without having to add 200 extra characters of code.
It's a switch. You are using SQL Server 2012, so look into FORMAT() function. http://technet.microsoft.com/en-us/library/hh213505%28SQL.110%29.aspx I'm not, so unfortunately I can't test anything out for you - but there are some date formatting improvements.
For those of us who aren't - , there are things you can do that will be great - once you get used to them. This isn't specific to SQL Server - but Week of Month varies from organization to organization - so you'd have to define that to get a good example for 3rd week of month, etc. Also, when using DATEPART with week or day arguments, what gets returned is determined by the setting for the first day of the week (1 -7 - ##DATEFIRST). The numeric styles for CONVERT (again check out FORMAT() if you're on 2012) are definitely not as intuitive - but you'll probably be using the same styles over and over, and you'll have them memorized quickly. If you are set on 'WMMYY' or just use something over and over that doesn't have a satisfactory built in solution- create a UDF.
data that was entered in during the month of june
DATEPART(mm,#date) = 6
current month
month(getDate())
Or this week
DATEPART(ww,GetDate())
Related
I have staging table which contains date as string with format 'mm/dd/yy'. I have Oracle 11g procedure to convert the string to date format before loading into main table. I'm using to_date('03/20/34','mm/dd/rr') to convert into date format which is giving wrong output as 03/20/2034 whereas the correct date is 03/20/1934. Please help me out to get the correct output where my table contains dates from both centuries.
"I'm using to_date('03/20/34','mm/dd/rr') to convert into date format which is giving wrong output as 03/20/2034 whereas the correct date is 03/20/1934. "
RR was a hack Oracle introduced in the last Millennium as part of the fight to resolve the Y2K bug. The standard date mask YY defaults the century to the current century. But in 1999 it was more likely that 01/01/00 meant 01/01/2000 rather than 01/01/1900. So the RR hack was to derive the century for dates using fixed windows pivoting on 00: values 00-49 are given century 20, 50-99 are given 19. Clearly some of the time this guess would be wrong, but the data corruption introduced was of a lower level than defaulting all dates to century 19.
The key point is, the windows are fixed. It was intended to be a temporary solution, because there wasn't time to switch all the legacy systems to use four-digit years before 2000 arrived. But the vision was always that all systems would be fixed in the long term, even if only through retirement or replacement. Certainly nobody expected that new systems would be built supporting two-digit years.
It is now 2017 and there is no excuse for systems to still be using two-digit years. Back in the old days storage was expensive, and shaving two digits from a date was a valuable space saving. Now it is just sloppiness.
Which obviously doesn't help you solve your problem. The short answer is there is no way to change the pivot used by RR. The best solution would be to enforce stricter validation on the data input aspect of your system, and insist on four-digit years. Whether that's feasible depends on your office politics. The other solution is to write your own conversion function:
create or replace function my_to_date (p_str varchar2) return date as
begin
if to_number(substr(p_str, 7) <= 35 then
return to_date(substr(p_str, 1, 6)||'19'||substr(p_str, 7), 'dd/mm/yyyy');
else
return to_date(substr(p_str, 1, 6)||'20'||substr(p_str, 7), 'dd/mm/yyyy');
end;
Obviously you'll need to define the actual rules for deciding whether to use 19 or 20.
I also encountered an issue like this, when inserting date values from the late 90s. The format in the script I was given read DD-MON-YY, so the database read that as 20YY, instead of 19YY.
My very inelegant solution was to open the raw data file and simply add a "19" before the YY year values.
I am working on my first application for mac which uses Core Data. Since I don't have much software development experience I would like to ask the more experienced developers the following question:
When entering data in some of the forms, user will have to enter a date in couple of the forms. Since app will be on app store and people from different continents will download it (I hope so) I am thinking of allowing the user to select his preferred date format from the preferences panel that I have in my app.
But I am wondering what will happen if after entering 500 or more records, he decide to change the date format again? Will that cause a mess in core data eventually?
Is this good idea or I should keep things simple and just get the system date (user computer date format) and use that date format? What would you do? Any advice will be deeply appreciated.
My advice is to keep date as timeinterval. You can see such method for NSDate.
The interval between the date object and 00:00:00 UTC on 1 January 1970.
So if you get NSDate object from NSDatFormatter object you will be able to obtain time in seconds since 1970. You could store this value in Core Data and use it later for creating NSDate objects. You will be able to use it for different locales and time zones as well as use the correct format.
'Dates' is complex topic and I suggest you to read guides about dates and date formatters.
First is to decide how you should store the date. The answer here is as an NSDate. The NSDate is a single unique precise point in time, thus it in a sense stores both date and time.
This means that for example 1 PM in Berlin and 8 pm in Kuala Lumpur will be the exact same NSDate value (during winter months) but 2 pm in London and 2 pm in Paris the same calendar date will not be the same NSDate value. This is a quite complex topic, read the date and time programming topics documentation from Apple.
Then as you say you need to allow you user to input the date. The way to do that is to use a NSDateFormatter tied to your input control. The formatter can be defined to be as per system settings, which means you will get the localisation you are seeking for free, so that is in fact easy.
The tricky thing you are really facing is to determine what you are really looking to store if it is only the calendar date without an associated time you want to store. For example you decide store the date combined with 12.00 noon in the local timezone. Then if the user shifts to another timezone more than 12 hours away the date may be displayed as the previous date or the next. The safest bet is to store the date combined with 12:00 noon GMT as this is in the middle of the time zone range. There are a few locations 13 and 14 hours off that could exhibit the mentioned problem anyway, but these are small atolls in the pacific and could possibly be safely ignored.
However the the best thing is if you can in fact determine that what you are looking to store is really a precise point in time rather than a date (which is a 24 hour fuzzy definition). For example in a calendar app an event usually takes place at a specific time on a specific date, then store that time and date.
I ran an SQL Query for Oracle which consists of Invoice date and Check date. When these data are copied on to an Excel Spreadsheet as text, it's dispayed as ex: "13-10-31" (Oct 31, 2013). However, when converted to date format, it's displayed as "10/13/1931". I've tried different date types but it always recognizes as the first part of the text as the day, then month, then year. I need these values to be setup as a date format as I need to calculate Days Payable Outstanding and other related ratios.
Is there any way to convert these values so that Excel recognizes the day, month, and year correctly? Would there be a macro that could automate this process for existing data and data that will be added in the future?
Thank you in advance.
Firstly, I hope the data type of your date column is DATE.
Secondly, the date should always have year as YYYY and not just YY. The world has already learned from Y2K bug.
If above two points are met, then while displaying use to_char(date_column, 'mm/dd/yyyy'). Thus, with YYYY format, there won't be any confusion between year and other fields.
Recently i was working with unit testing for my project.
I've given a task to test the method. The method should return the recent quarter date as per the current system date.
So, I've called the current system date using the following c# code:
string currentYear = DateTime.Now.ToString();
When i run the query it worked as expected.
So, its time for my tactics to raise a bug for that method. Hence I've changed the system date to 10/01/14 (dd/mm/yy).
Also I've customized current system date format to only keep last two digits of the year.
Ex: if year is 2014 the it shows only 14.
You can observe the short date and the long date in the following image.
When i run/debug the test in Visual Studio 2012, it still displays as 2014 as the current system date though I've modified it to 14.
Question: The real question is how did the system/program took the current year as 2014 even the system date is changed to 14. It may be silly but my doubt is Why it is not 1914 or 1814 and why it is 2014 ?.
Where did it store the current date or year information ? Does windows manage this stuff or did the C# taken care of the date ?
The real question is how did the system/program took the current year as 2014 even the system date is changed to 14. It may be silly but my doubt is Why it is not 1904 or 1804 and why it is 2014 ?.
C# only retrieved the date from the system, it was Windows that determined what data to send.
In the case of two-digit dates, Windows allows you to define what they mean in the Regional and Language applet in the Control Panel. This way you can specify the range you want it to represent depending on your usage.
The display of a date is not how it is stored, just how it is displayed.
January, 1st, 2014 may have a multitude of different formats, e.g.
2014-01-01
01-01-2014
01-01-14
1/1/14
Jan/1/14
001-2014
But all are held internally exactly the same way.
Note the advanced settings on your screenshot - this will indicate to many windows programs how to interpret a year entered as 2 digits, so it knows if it should regard a date entered as XX as 19XX or 20XX - this will cover manually entered dates, not the system date
Your C# application didn't store that date, Windows handled it for you.
As Sean mentioned, by changing from YYYY to YY you only changed how the date is displayed, not how it is stored. Windows doesn't store its system time information into a specific date format. Instead, it records the number of 100-milisecond intervals since 00:00 January 1st, 1601. That way it keeps the tracking of time independent of how it's displayed and allows you to display the date and time in a number of different formats.
As a curiosity, that specific date was chosen because the Gregorian calendar operates on a 400-year cycle (when it starts to repeat itself) and 1601 was the first year of the cycle that was active when Windows NT was being developed.
On a side note, Unix systems store that information as Unix Time or POSIX Time, counting the number of seconds elapsed since 00:00 January 1st 1970.
I work in a large scale IT support environment. Twice now we have seen an invalid date of 02/31/2157 being inserted in an Oracle DATE column. So far I have not been able to reproduce this problem, but it appears to be happening occasionally when a user attempts to save '00/00/0000' into the column. I believe the value is originating from a PowerBuilder DataWindow update.
The application uses myriad libraries for all sorts of technologies, so this question may be a bit vague, but...
Has anyone seen the date 02/31/2157 in some established library that Oracle could be defaulting to when some other invalid date is entered? Perhaps an end-of-time concept analogous to the beginning-of-time date of 1/1/1970?
From http://download.oracle.com/docs/cd/B19306_01/server.102/b14220/datatype.htm#i1847"
Oracle uses its own internal format to
store dates. Date data is stored in
fixed-length fields of seven bytes
each, corresponding to century, year,
month, day, hour, minute, and second.
2157-256 = 1901, which seems suspiciously close to a possible epoch of 1/1/1900 (or 12/13/1901 - which is the rollover date for the Year 2038 Problem)
I'd guess that it is storing either 0x00 or 0xFF in the date bytes, then getting confused when it decodes it. (How does it deal with month 255?)
Turns out this was a powerbuilder issue. The field was created in the datawindow as required, but was programmatically changed to be non-required before saving. So a null value was being saved to a non-null database column, and powerbuilder inserted some dummy date instead of just throwing an error.
I remember getting a weird value when saving an invalid date. IIRC it was in PB 9 and we had to get an EBF for it. It was a problem with Date Editmasks and entering an invalid date that wasn't rejected. Sorry I don't have more details.