Dates month names language in Oracle? - string

I have a varchar field in my table which contains a date, formatted as: Dic 31 1999 12:00AM, which can generally be converted without any problems using a to_date configuring 'Mon DD YYYY HH:MIAM'.
Month names can of course come in any language. For instance, January, would be Jan in English and Ene in Spanish.
I reckon the Oracle client will pick up the machine's locale to figure which is the language of the incoming string. The only problem is that this will not always work if you are a server where you can't really know where the date is coming from.
My current problem is that every time I'm in a Spanish set computer and try to process a date with English named months, I'll get an "invalid month" error.
Is there I way I could tell Oracle, on execution time, which is the language I'm sending?
The current ugly workaround is to translate not matching months to Spanish.

You should use NLS_DATE_LANGUAGE for that:
select to_char(sysdate, 'dd Month, Day', 'NLS_DATE_LANGUAGE = turkish') from dual

You can use SELECT * FROM NLS_SESSION_PARAMETERS to determine you current language settings (also NLS_INSTANCE_PARAMETERS and NLS_DATABASE_PARAMETERS exist).
Use NLS_* environment variables on your workstation or ALTER SESSION statements within your SQL session to change these language settings.

ALTER SESSION might work. I don't remember exactly how, but I know you can set locales, date styles and number formats with it.

Related

How to properly format dates in Google Sheets or Microsoft Excel

I have a spreadsheet I need to make in Google Sheets. The source of some of the data is exported to an Excel sheet. The data arrives in a dd/mm/yyyy format and I need to display it in a MON d format (Ex Sep 5).
The problem is both excel and sheets look at the date that arrives and think it is mm/dd/yyyy.
For example, 02/08/2022 is believed to be Febuary 8 even though it should be Aug 2. The problem then arises that neither of these platforms end up knowing how to convert this to Aug 2 and I end up having to do this manually.
Does anyone know how to get around this?
I have tried adjusting the format of the date, as well as using DateValue to convert (this fails since it understands the date as mm/dd/yyyy even when it is dd/mm/yyyy).
Any leads would be appreciated!
Thanks!
In Google Sheets, choose File > Settings > Locale and select a locale that uses the dd/mm/yyyy date format, before importing the data. You can then format the date column the way you prefer.
in gs:
=TEXT(REGEXREPLACE(A1&""; "(\d+)\/(\d+)\/(\d+)"; "$1/$1/$3"); "mmm d")
Try the following and format the result to your liking
=INDEX(IF(ISNUMBER(U2:U5),U2:U5,
IF(U2:U5=DATEVALUE("1899-12-30"),,
(MID(U2:U5,4,3)&LEFT(U2:U5,3)&RIGHT(U2:U5,4))*1)))
(Do adjust the formula according to your ranges and locale)
Functions used:
INDEX
IF
DATEVALUE
ISNUMBER
TRUNC
MID
LEFT
RIGHT
Well, for a formulaic solution, if the date is in A1, then the following places the correct date in B1:
=DATEVALUE(TEXT(A1,"DD/MM/YYYY"))
The TEXT function makes a string that will be the same form as your imported string out of the date produced during import. DATEVALUE then gives the proper date you desired.
The trick is in the TEXT step in which you reverse month and day in the string for DATEVALUE.
Naturally, instead of a helper column, it could just be wrapped around any reference to a date from column A, though one would have to remember to do so for all the years the spreadsheet is in use.
If you are importing, not just opening a .CSV file via File|Open and going from there, you have an opportunity to solve all your problems. You use the Ribbon menuing system's Data menu, select the very leftmost thing, Get Data and from the (no arguing THIS isn't a menu) menu that drops down, Legacy Wizards, then finally From Text (Legacy) which will open the old Excel Import Wizard. (You may notice this is very like the Data|Text to Columns Ribbon menu choice and that is because that choice is the old wizard minus the steps at the start that go looking to another file for the data because it knows, by law, that it has to already be in the spreadsheet... in other words, it looks the same because it IS the same.)
Then make selections for the first couple dialogs it presents you to get to the dialog in which you tell it to import columns as whatever: general (let Excel decide), text, date, and do not import. Choose Date and make the selection of DMY to import them properly as you desire them to be so you are never presented with the problem at all.
As you might guess, you can use the abbreviated wizard via the "Text to Columns" feature to do the same thing after import when you see they are reversed. Since it is a single column of data, the result will overwrite the original simplifying your work.
Why does this happen at all? Well, the "locale" folks have the idea. When Excel imports numbers that are in a form it recognizes could be a date, it looks to the operating system settings for the selected ways dates are understood. So if your operating system believes a date should be displayed "Month Day, Year" and Excel has a set of data it thinks fits that mold, it will convert them all using it. So you get those Feb 8's rather than Aug 2's.
Interestingly, it does two other things of note:
It looks at 8, count 'em, 8 rows of data to decide the data fits the pattern. Even with 1,000,000 rows to import, it looks at... 8.
Then it does them ALL as if God himself wrote the "8"... and dates like 25/03/2022 get imported as text not a real date, because they (oh, obviously) can't be dates... "25" can't be a month!
It IS possible to change settings (DEEP settings) to make Excel consider X number of rows in a data set before deciding such things. I found them here, on the internet, once upon a time, though I shouldn't like trying to find them again. It will consider up to a million rows in such an import, but... that'd make it pret-ty slow. And that's a million rows for EACH data column. I won't even say that "adds up" - I'll point out it "multiplies up."
Another technique is to add some number of starting rows to force the desired pattern onto the import. I've heard it works in TIME column imports so it ought to in DATE column imports but I've not verified such.
My bet is you will find the use of the "Text to Columns" feature of most use if you can use a hands-on approach - it does require literal action on your part, but is a fast operation. If you will see others using the spreadsheet though... well, you need a formulaic solution or a VBA one (macro with button for them to have some fun clicking as their reward for doing what they were trained to do instead of complaining to the boss you make bad spreadsheets). For a formulaic solution, the above formula is simple.
Last thought though: there's no error-checking and error-overcoming in it. So a date like "25/03/2022" in the data that imported as literal text is a problem. For handling the latter, an up-to-date approach could be:
=IF(TYPE(A1)=1,DATEVALUE(TEXT(A1,"dd/mm/yyyy")),DATE(INDEX(TEXTSPLIT(A1,"/"),1,3),INDEX(TEXTSPLIT(A1,"/"),1,2),INDEX(TEXTSPLIT(A1,"/"),1,1)))
in which the DATE(etc. portion handles finding text of the "25/03/2022" kind. Lots of less up-to-date ways to split the text Excel would have placed in the column, but since demonstrating what to do if it existed was the point, I took the easy way out. (Tried for a simple version but it wouldn't take INDEX(TEXTSPLIT(A1,"/"),1,{3,2,1}) from me for the input parameters to DATE.) TYPE will give a 1 if Excel imported a datum as a date (number), and a 2 if brought in as text. If empty or strange strings could exist, you'll need to deal with what those present you as well.

Excel bug: TEXT function doesn't work to extract day name depending on region

How to compute day name from date in Excel?
Please don't say it is TEXT(...,"ddd") because it doesn't work
Another screenshots for non-believers:
Complete formula just doesn't work too:
This is some problem with locale processing. Although my Windows in English, my region is Russia and Excel uses it in some strange places:
TEXT(...,"ddd") ( or TEXT(...;"ddd") . as required )
does work, provided you either SUBSTITUTE the dots . in your data for recognisable date separators first (eg /) or apply Find/Replace for that purpose. Though having done either (perhaps working on a copy) no formula is necessary since merely a Custom format of:
dddd
(long form, or ddd short) should be sufficient.
Note that without indication of the century Excel will guess which and not give you the right answer for a date such as 11.11.1911 (Armistice Day, a Saturday) represented in text as 11.11.11.
With string parsing you would need to be careful whether 10.08 represents October 8 on your system, or August 10.
We can always manually build one : =if(WEEKDAY(A1,2)=7,"Sunday",if(WEEKDAY(A1,2)=6,"Saturday",if(WEEKDAY(A1,2)=5,"Friday",if(WEEKDAY(A1,2)=4,"Thursday",if(WEEKDAY(A1,2)=3,"Wednesday",if(WEEKDAY(A1,2)=2,"Tuesday",if(WEEKDAY(A1,2)=1,"Monday","")))))))
[^_^]

Importing Excel to Access: Date be field name for Access table

I was trying to import an Excel worksheet into Access table and the worksheet had specific dates(E.g. 12/4/2017) as headers for columns.
And when i tried to import to Access, Access did not allow me to import that worksheet into table as "12/4/2017 isnt a valid field name"
Is there other ways to import the worksheet or work about this?
Thanks
Names of fields, controls & objects in Access:
Can be up to 64 characters long.
Can include any combination of letters, numbers, spaces, and special characters except a period (.), an exclamation point
(!), accent grave (``) or brackets ([ ]).
Can't begin with leading spaces.
Can't include control characters (ASCII values 0 through 31).
Can't include a double quotation mark (") in table, view, or stored procedure names in a Microsoft Access project.
(Source)
Date and time values in Excel are stored internally as a 64-bit floating point number. The value to the left of the decimal represents the number of days since December 30, 1899. The value to the right of the decimal represents the fraction of a day since midnight.
For example:
12:00 Noon is stored as 0.5.
1.0 represents midnight on January 1, 1900.
2.25 represents 6:00 AM on January 2, 1900.
Your example date 12/4/2017 would be stored as 43073.
Interpretation of datetime's depend on customization of regional settings according to Microsoft (not necessarily the country's government standard date format). For example, I live in North America, so by default, Excel would interpret 12/4/2017 as a date.
However, for various reasons, I prefer a date format of YYYY-MM-DD (technically named "ISO 8601"), so I changed the format in my Windows Settings. Therefore, when I enter 12/4/2017, Excel does not recognize it as a date, so it is stored as text, yet when I enter 2017-12-4, Excel knows to store it as a date.
Regional settings aside, I suspect that your field names may have times attached to them (even if they aren't formatted to display as such).
If the cell you'd like to use as a field name actually contains:
April 12, 2017 6:00 AM
which, if formatted as M/D/YYYY, "hides" the time, to display as:
12/4/2017
even though it is actually stored internally as:
43073.25
Given the Access field names can't contain a period (see above), Access becomes "confused" with the fraction of a day (.25).
Make sure your dates to be used as field names don't contain times.
You could:
Format the row that has the field names as text.
Right-click the row number and choose Format Cells.
Under the Number tab, choose Text
Use a function to remove the times:
If B1 contains a datetime you want to use as a field name in A1, you could use the Int function in cell A1 (to round the value down to a whole number):
=Int(B1)
The fraction (time) is removed but the value is still stored as a number/date.
Use a function to convert the datetime to text:
If B1 contains a date you want to use as a field name in A1, you could use the Text function in cell A1:
=Text(B1, "M/D/YYYY HH:MM")
As you can see in the image, Access allows me to use the dates as field names if they are properly formatted:
Related Further Reading:
TechRepublic: Techniques for successfully importing Excel data into Access
Office.com: Guidelines for naming fields, controls, and objects
ExcelTactics: The Definitive Guide to Using Dates and Times in Excel
Microsoft: How to use dates and times in Excel
Stack Overflow: MS Access - Date as Table Field Name
A note about Database Normalization:
Just because you can use dates as field names, that doesn't mean that you should. It is generally considered poor database design to have a field name so specific.
Perhaps your intention is to import the poorly-structured data into Access to fix this issue, but if not, you should consider storing the data in a more organized way that is conducive to database expansion and normalization.
If your data has date-specific field names:
...then the date should be added as part of the record, not as a field name:
...although this is still not normalized. Normalization is about optimizing efficiency and allowing for expansion, so perhaps the database could be setup more like:
With this method it would be database expansion and data analysis would be more logical (perhaps making it easier to find trends in Jane's troubling eating habits).
Alas, I digress. There is plenty of information available online about database normalization, to suit any experience level.
Further Reading about Normalization:
Wikipedia: Database Normalization
Microsoft: Description of Database Normalization Basics
ThoughtCo: Database Normalization Basics
Stack Overflow: Database normalization - who's right?
EDIT: (the result)
You didn't mention which method you're using to import the data from Excel to Access, which may be relevant (as there are several possible combinations). Access might handle the source data differently if your Excel data is saved in an XLSM vs XLS vs CSV, etc. Data could be imported using the New Source Data…from File interface, vs programmatically with VBA, or even other languages. Therefore, if you can't get one method working (with the dates formatted a specific way), try one of the other combinations.
For simplicity's sake, I used the built-in interface with an XLSM into an ACCDB. The result is demonstrated below:
Note that it worked even though I included times in the headers (and would work without times), since they are properly formatted as text, and First Column Contains Column Headers is selected.

categorizing documents depending on their date fields

I've been stuck with an annoying problem for a while that I can't fix. I have a field in all of the documents that represents time- a date in format dd.mm.yyyy.
What I'm trying to do is to categorise them- Show the documents that have todays date, that will have todays date in closest 7 days, etc.
Here's the code (formula for the categorized field) that I have:
#If(#Today > pi_due_date; "Late docs"; #Today=pi_due_dat; "Todays docs";((pi_due_date - #Now)/86400)>0 &((pi_due_date - #Now)/86400)<7;"This weeks docs";"Future docs")
Everything was fine until today (after 12:00 PM) I noticed that this part: #Today=pi_due_dat; "Todays docs"; does not work, it does not return the document in the "Todays docs" category. Pretty much the same thing is happening to all the other categories and I don't understand what is causing this problem.
pi_due_dat is missing the 'e' at the end.
Assuming it is more than that, though, you'll want to make sure that you are only comparing the dates and not a date/time.
Try #Date(pi_due_date) = #Today instead.
I would like to point out that using #Today or #Now in a view (selection criteria or column value) will create serious performance issues, as the view will be constantly re-indexed. It will affect all applications on that server as well.
You may want to rethink the design, perhaps have a scheduled nightly agent that set a flag on the documents to indicate how they are boing categorized.

how to search for latest content on google?

in google search box when we type something like " 'java code' + inurl:javalobby " we will get the search results where the website link contains the string javalobby and the page will contain the string java code.
Similarly is there a way to search the latest updated content in the internet which will contain the keyword entered in the search box ?
Thanks.
There are two tricks in google to narrow your search based on date. It is using either the keyword daterange:startdate-enddate or by content creation date.
1. Using the syntax daterange:startdate-enddate : The catch is that the date must be expressed as a Julian date, a continuous count of days since noon UTC on January 1, 4713 BC. So, for example, July 8, 2002 is Julian date 2452463.5 and May 22, 1968 is 2439998.5. Furthermore, Google isn't fond of decimals in its daterange: queries; use only integers: 2452463 or 2452464. You can convert Julian dates online here.
Example:- Geri Halliwell left the Spice Girls around May 27, 1998. If you wanted to get a lot of information about the breakup, you could try doing a date search in a ten-day window—Say, May 25 to June 4. That query would look like this:
"Geri Halliwell" "Spice Girls" daterange:2450958-2450968
2. Searching by content creation date : Try adding a string of common date formats to your query. If you wanted something from May 2003, for example, you could try appending:
("May * 2003" | "May 2003" | 05/03 | 05/*/03)
A query like that uses up most of your ten-query limit, however, so it's best to be judicious— perhaps by cycling through these formats one a time. If any one of these is giving you too many results, try restricting your search to the title tag of the page.
If you're feeling really lucky you can search for a full date, like May 9, 2003. Your decision then is if you want to search for the date in the format above or as one of many variations: 9 May 2003, 9/5/2003, 9 May 03, and so forth. Exact-date searching will severely limit your results and shouldn't be used except as a last-ditch option.
When using date-range searching, you'll have to be flexible in your thinking, more general in your search than you otherwise would be (because the date-range search will narrow your results down a lot), and persistent in your queries because different dates and date ranges will yield very different results. But you'll be rewarded with smaller result sets that are focused on very specific events and topics.

Resources