Formatting Date according to regional settings in VBA - vba

I am extracting several dates from an e-mail body.
It is random, so it could be a date in English, Spanish or some other format.
I need to get this date and convert it to the user's profile date settings.
E.g: **User profile is English language**
I receive 15/jun/2015 or 15-junio-2015 or 15/06/2015
The output jun/15/2015 or june-15-2015 or 06/15/2015
What would be the easiest way to do such task?
Thanks.

You may find the Format functon available in VBA helpful. But I think it may not help in case of other languages, you will need to use the DateValue function which returns a Date value containing the date information represented by a string, with the time information set to midnight (00:00:00).

Related

make program to work with different language/date format vb

I coded a program for work to keep tracks of our projects linked to an access database. The code is written in VB.NET
The thing is I use a computer with dates in French. The whole thing is coded according to that language. But now I have to install the program on all the computers in the company (some are in French and som in English). I can't change the language of the english computers because of another program they're using.
So how can I make my program to work with English dates?
I tried to detect the language of the computer this way:
CultureInfo.CurrentCulture.DisplayName
And then to convert the Today date to French (I'm using the Today date to compare it to a due date for "Alarms" to prevent us when a project is late or due for today):
Today = Today.toString(CultureInfo.CreateSpecificCulture("fr-CA")
But this doesn't seem to be the right way to do it since my program doesn't load afterwards.
If you have any idea, I'm willing to read them
Thanks guys
Based on that description, there is no problem other than the one you are creating. DO NOT convert dates/times to Strings unless you actually need Strings. You do not.
In the case of the DateTimePicker, you simply set the Format to Long or Short and the user will then see dates in a format appropriate to their system, based on their current culture settings. In code, you get a DateTime value from the Value property and that is a binary value, so format is irrelevant.
In the case of the DataGridView, if you have a column that contains DateTime values then they will be displayed in a format based on the current culture. The underlying values are binary so they have no format but the grid must use a format for display purposes. Each user will see what they expect because the system's culture settings will be used to perform that format. If you don't like the format used, you can set the DefaultCellStyle.Format property of the column to "D" or "d" to match the Long and Short formats of the DateTimePicker respectively.
As I said, the values in the cells of such a column are DateTime values, not Strings, so format is irrelevant. If you want to compare them with today's date then you do so in binary format, e.g.
If CDate(myDataGridViewCell.Value) > Date.Today Then
At no point do you have to worry about format because the application will use the current system culture settings automatically anywhere that format is an issue.

use Datetime to do a query in SQL database

I need to retrieve a tuple from the database that have a DateTime as a primary key, the problem i'm having is that it's only working with Datetime's that have the time before midday, otherside it fails to retrieve anything, here is the code:
string fecha = "22-11-2016 15:56:50";
DateTime myDate = DateTime.ParseExact(fecha, "dd-MM-yyyy HH:mm:ss", System.Globalization.CultureInfo.InvariantCulture);
modelo.solicitud = BD.Solicitud.Find(myDate);
in resume I get a null in modelo.solicitud
if the string fecha is like "01-01-2017 09:00:00" (before midday) it success to retrieve from database, but if it's like "01-01-2017 16:00:30" will fail to retrieve a thing..
Any help of recomendation will be appreciated..
Regardless of the DBMS you are using, fields (columns) that are defined as DATETIME are stored as a binary value. What you see is a generated string representation of the binary value according to either the defaults defined for the DB or a specific format you define for presentation.
You can try setting the default datetime format to something like 'yyyy-mm-dd hh24:mm:ss' (hh24 is Oracle's way to say that you want the hours part to be in the 0-23 range; you will need to check how this is done in your case).
This format also removes ambiguities related to the American/European way of writing dates (i.e. mm/dd/yyyy in the US vs. mm/dd/yyyy in Europe, such that 3/4/16 would mean March the 4th 2016 in the US but April the 3rd 2016 in Europe).
Last, the Spanish word resume has a different meaning than in English (you would normally say summary).
Hope this is clear for you now.

Why does CDate("0/5/14") return 5/14/2000?

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.

Date format error on user's computer dependent

Here is my problem. the date that i got from my database contains "12/31/2013". Based on this date, the format is mm/dd/yy. Now the question is how do i makes it that no matter what format of the date in the user's computer, they will always read the date "12/31/2013" as mm/dd/yy instead of example dd/mm/yy which when it reads it contains an error due to there is no 31 month. i try the split method on the date i receive from my database but i coudn't get it to confirm to the format that is independent from the user's computer
Is your date being stored in your database as an actual date format, or as a string?
Remember that DateTime.Parse by default, uses the current user's current system date/time formatting settings (so UK users are dd/MM/yyyy, but US users are MM/dd/yyyy). If you want uniform parsing then use DateTime.ParseExact and specify an exact parsing format string.
One rule of thumb that's useful to remember is that "if you're ever using String.Split, you're probably doing something wrong" (I'll make exceptions for quick-and-dirty by-design programs, but for parsing a Format-string, Regular-expression, or Finite state machine is more performant (less string allocations) and less brittle.
Back on-topic, if your database is storing objects as a date or datetime then don't use strings at all. Use the .GetDateString(int) method of IDataReader or typed field properties of EF classes.
How did you get a date from your database? Did you store the date as a string? If at all possible, consider keeping the date as a DateTime variable rather than a string. If not possible, look into the DateTime.TryParse method which supports internationalization and should be able to understand with the user's UI localization settings.
Its not clear if you want to read the same format from the database or display it on the screen (UI)
If its from the sql server, consider using convert <- follow this link

Displaying Time Zone information in Reporting Service Reports (SQL 2005)

I have a Microsoft SQL 2005, reporting project. I want to display the Current date, time and timezone information on the page header. That is, I want to get a display as below
6/17/2009 12:25:11 PM +05:30
I added a text box to the page header. When set its expression to =Now, used the FormatDateTime function but they all either display only, date or time or date & time but not the timezone.
When I set the Format property of textbox to "o" and I got the following display 2009-06-17T12:37:36.2347500+05:30. This does have the timezone, but date and time info is not very friendly.
Is there anyway I can display the current date time and timezone info the the format (6/17/2009 12:25:11 PM +05:30) I require?
Thanks
Shreedhar
use
DateTime.Now.ToString("MM/dd/yyyy HH:mm:ss tt K")
Please use this:
DateTime.Now.ToString("MM/dd/yyyy hh:mm:ss tt K")
Be careful with the format you define "friendly". Since you want to display the timezone I suppose your app has to be used by people living all over the world: for most of them the format "MM/dd/yyyy" is not friendly at all.
Think of a date like "06/10/2009": for English people it's clearly the 10th of June, but for Latin people it will likely be the 6th of October.
The ISO format is not very friendly, I agree, but the informations are displayed in a hierarchical order from the greatest to the smallest. Besides almost nobody uses natively it, and this can be a plus, since everybody will have to understand what it is looking at, without making false assumptions based on his/her locale.