I have a lot of different date format that one of my field can contain. And I'm trying to parse it but it some times doesn't understand the format at all and returns 1900-01-01.
Or sometimes, it invert months, days and year: 2023-12-11 instead of 2012-11-23.
The field is contained in a total of 1500-2500 excel files, that are produced by some kind of scanner. Dates and time are in different cases.
I've seen different formats such as these so far:
yyyy-mm-dd or mm/dd/yy and some others (that i cant find because i dont want to spend the day oppenning random excel files hoping to find a different format ^^')
So... I've tried parsing it at hand (Substring of the different fields), but it still has bugs, so:
Is there any date parsing tool for VB that works often?
I imagine there is a library or something that can parse dates from almost any format already coded, and if I could avoid to recode it I'd be quite happy :)
No, of course there is nothing that can parse dates in any (unknown) format. How should it know what to do with 9/10/11? That can be anything.
So you can use TryParse or TryParseExact (you can even pass a string[] for multiple allowed formats) and pass the correct CultureInfo.
Related
I am looking for a VBA function that would return the current OS Short date format (ex: M/d/yyyy, dd-MMM-yy, yy/MM/dd, etc.) as a string. I have found such functions for MS Excel on related posts using Application.International, but they do not work with MS Access.
I want to be able to show the OS date format in my forms to avoid confusion if '08-11-11' is displayed, for example. Using CDate(), my dates are automatically formatted to whatever is set in Windows Date and time settings. However, users might not be aware of that.
Just pull it from the registry.
There are many ways, the way I use:
CreateObject("WScript.Shell").RegRead("HKCU\Control Panel\International\sShortDate")
Of course, one could use WinAPI to read the registry too.
If reading the registry is really undesirable, you can always format a distinct date, for example:
Format(#2/1/3333#, "Short Date")
And then parse the result to get the format
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.
I I'm busy with editing my stored procedures for Reports i created a while back.
I encountered a problem where the parameters being sent to the stored procedures comes in all kinds of funky formats from multiple computers.
Some of the formats i have encountered has been
'2017-01-31'
'2017-31-01'
'01-01-2017'
'31012017'
'20170131'
I desperately need a way to handle all these different formats.
the '31012017' gives me a input error so it doesnt even want to reach my Converter so i made the input parameter a VARCHAR(15) to take all kinds of inputs.
You can make some educated guesses on the date format, there's however limit on how much you can guess.
Canonical dates ussually are ISO compatible so yyyy-mm-dd - I've never seen something like 2017-31-01.
The problem is when you get something like 11-11-2011 or - even worse - 10/11/12. There's no way to figure that out if you have no additional information.
The best possible fix i found was the following(works for almost all formats)
https://i.stack.imgur.com/MLARE.png
This way it picks up which format whatever PC you are using is using and sends a standardized format to SQL
I am working on creating a search mechanism where the user can specify which fields to search on, the operators to use and the values to search for. More like an advanced search. However, I also need to search for dates and date ranges but the problem is that dates are declared as NSStrings and not NSDates. So basically they are strings that represent dates (and not literally dates as I am referring to them as). An example of a string that represents a date in the database is: 2014-11-25T00:00:00+1000.
So, without changing the values and their respective fields to NSDates in a migration, is there a way to keep what we already have but instead specify a sort of conversion criteria for my predicate query so that Core Data can convert the NSString field values to NSDates and then do the comparison to determine weather a record fits into the specified criteria or not?
I'm fairly sure that CoreData can't convert NSStrings into NSDates for you, what you'll have to do is create a parsing algorithm that converts it for you. The format looks like it's an ISO8601 date format, which is used in web development, so I'm assuming you've downloaded this data from somewhere?
I've developed date parsing algorithms before and with proper testing you can build something quite robust, quite quickly. What you can do then is convert your NSDate's into strings and then feed those strings into your fetch predicates.
There is a problem in VBA text box while filling input mask property:
I am trying to make the combination of date and time:
Hence i put it like below:
00/00/00;0;_00:00;0;_
But while running the application, i am only getting 00/00/00 (Date).
But i remember, i got the result as like 00/00/00 00.00 as expected when i first put the expression as like above;
but now i am not getting it :-(
The InputMask property can contain up to three sections separated by semicolons (;)
Your mask should be like this:
"00/00/00 00:00;0;0"
or
"00/00/00 00:00;0;_" // to display it like __/__/__ __:__
Why not just use the built in "General Date" format? I've found over the years that input masks are very restricting and basically a pain. Although it's been so long since I've used them that I don't recall the details of why I despise them.
This also has the benefit of respecting the users choices of regional date format. For example I always use yyyy-mm-dd format.
Also a client had a situation where the date format was decreed to be Medium Date on all fields. Which is dd-mmm-yy. It later turned out that in a table of 100K records there were twelve dates before 1900. They had simple had something extra keyed in in the year so Windows/Access interpreted those dates as being in the 3rd or 5th century or whatever. Now these dates weren't used in any kind of calculation so it wasn't a big deal. SQL Server upsizing to small date/time fields didn't appreciate those though.