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
Related
I have written a program that logs events into a db file as they happen using SQL statement. Whenever I open the table to view, I specifically request the dataset in descending order based on ALARM's date and time. It seems to work only for part of the table. I am using SQLite3 and my program is written in delphi or Pascal.
Here is the SQL statement:
SELECT *
FROM Alarms
ORDER BY datetime(ALARMTIME) DESC
Here is a snapshot of the table. Pay attention to the red arrows. That's where Alarm's date and time doesn't follow descending order. I don't know why this is happening.
I'm not sure how you created your date/time string in your database since that information wasn't given in the question. However, according to the documentation for the datetime() function, the format you have of MM/DD/YYYY HH:MM:SS xx is not one of the accepted formats. In fact, if you do SELECT datetime('1/23/2018 01:40:00 PM') at an SQLite prompt, you get NULL. Whereas, if you use an acceptable format, you do not: SELECT datetime('2018-01-23') gives '2018-01-23 00:00:00'.
So I think the solution is to write the ALARMTIME field using datetime('now'), which does yield a format accepted by datetime(). If you need to sort based upon the format you have now, you can't do it with datetime(). You'd need to reformat the field using string functions to get it in a form you could do a string compare with (e.g., as is done here).
The OP has indicated in a comment that the ALARMTIME is set using the following Pascal code:
FieldByName('AlarmTime').AsDateTime := now;
There's no guarantee that Pascal is going to use a date/time string format in this context that is compatible with SQLite's datetime() function. So Pascal date/time formatting functions can be used to create a format more specifically acceptable by SQLite's datetime(). Then you'd use something like:
FieldByName('AlarmTime').AsString := FormatDateTime('YYYY-MM-DD hh:nn:ss',now);
Now this will change the default view of the date to YYYY-MM-DD .... If you still want your view of the table to show MM/DD/YYYY... then you'll either need to go back to my prior comment about processing the string on the fly in the comparison for sort, or write a little view formatting code so that it displays in a format that's different than what is stored internally, which is a common view/model separation technique.
If you can write your original ALARMTIME format as MM/DD/YYYY and make sure you pre-pad with zeroes (e.g., 01/09/2018 not 1/9/2018) then you can use SQLite's substr function:
SELECT * FROM Alarms
ORDER BY (substr(ALARMTIME,7,4)||substr(ALARMTIME,1,2)||substr(ALARMTIME,4,2)||substr(ALARMTIME,11)) DESC
And you would create your ALARMTIME using this:
FieldByName('AlarmTime').AsString := FormatDateTime('dd-mm-yyyy hh:nn:ss', now);
The above solutions are fairly generic. Depending upon the client library you are using (which you have not specified), there may be another more suitable approach to solving the problem.
You cannot do, for example, SELECT * FROM Alarms ORDER BY ALARMTIME DESC and get an accurate sort since, for example, the date 12/1/2018 would come after 2/1/2018 in that sort ordering even though 2/1/2018 is later in time. This is because 2 follows 1 in the ASCII collating sequence.
If you need to keep your current ALARMTIME string format and not change how you're saving it, which is somewhat free form m/d/yyyy in which the day or month can have one or two digits, you're going to have a bit of work to do in order to sort it if your client library doesn't support some helpers in this regard. Perhaps your only other option would be to use a custom SQLite function. These are written in C and compiled and linked with SQLite. You'd have to find one already written, or write your own.
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 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.
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
Is there a way to change the default format of a date in Postgres?
Normally when I query a Postgres database, dates come out as yyyy-mm-dd hh:mm:ss+tz, like 2011-02-21 11:30:00-05.
But one particular program the dates come out yyyy-mm-dd hh:mm:ss.s, that is, there is no time zone and it shows tenths of a second.
Apparently something is changing the default date format, but I don't know what or where. I don't think it's a server-side configuration parameter, because I can access the same database with a different program and I get the format with the timezone.
I care because it appears to be ignoring my "set timezone" calls in addition to changing the format. All times come out EST.
Additional info:
If I write "select somedate from sometable" I get the "no timezone" format. But if I write "select to_char(somedate::timestamptz, 'yyyy-mm-dd hh24:mi:ss-tz')" then timezones work as I would expect.
This really sounds to me like something is setting all timestamps to implicitly be "to_char(date::timestamp, 'yyyy-mm-dd hh24:mi:ss.m')". But I can't find anything in the documentation about how I would do this if I wanted to, nor can I find anything in the code that appears to do this. Though as I don't know what to look for, that doesn't prove much.
Never mind :'(
I found my problem. I was thinking that I was looking directly at the string coming back from the database. But I was overlooking that it was reading it as a Timestamp and then converting the Timestamp to a string. This was buried inside a function called "getString", which is what threw me off. I was thinking it was ResultSet.getString, but it was really our own function with the same name. Oops. What idiot wrote that function?! Oh, it was me ...
Thanks to all who tried to help. I'll give you each an upvote for your trouble.
I believe the table columns are specified differently. Try these variants:
timestamp
timestamp(0) no millis
timestamptz with timezone
timestamptz(0) with timezone, no millis
With which client are you running the select statements? Formatting the output is the application's responsibility, so without knowing which application you use to display the data, it's hard to tell.
Assuming you are using psql, you can change the date format using the SET command:
http://www.postgresql.org/docs/current/static/sql-set.html
Which is essentially a way to change the configuration parameters. The ones that are responsible for formatting data are documented here:
http://www.postgresql.org/docs/current/static/runtime-config-client.html#RUNTIME-CONFIG-CLIENT-FORMAT
Daniel tells me to post my findings as an answer and accept it to close the question. Okay.
I found that the date format I was seeing that did not include a time zone was not what was coming directly from Postgres, but that there were a couple of function calls that I was missing that converted the incoming date to a java.util.Timestamp, and then from the java.util.Timestamp to a String. It was in this conversion from the Timestamp to the String that the time zone was defaulting to EST.
In my own humble defense, my mistake was not as dumb as it may sound. :-0 We had the execution of the query in a subclass that read the results into a List, which we do to allow modification of the query results before output. (In this case we are adding a coule of columns that are derived from the stored columns.) Then we have a set of functions that resemble the JDBC functions to pull the data out of the List, so a calling program can easily switch from processing a query directly to processing the List. When I was wrestling with the date format problem, it just didn't register on me that I wasn't looking at "real JDBC", but at "simulated JDBC" calls.