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
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'm trying to write a schema for an ActiveRecord object.
I've decided to use iso8601 format throughout my application, including for external api requests.
Should the column be a string or datetime?
Is there any performance impact or distinction between the two?
Storing the date in the database as a date or datetime means you can use the date functions like comparing dates in the database. And it gives you the freedom to present the date in whichever format you choose, making it easy to do so if the formatting requirements change in the future, without having to touch the database.
Whereas storing the date in the database as a string removes all these advantages. You no longer can use database date functions. Plus, If you decide to use another format (maybe in a newer version of the API or for mobile apps... etc), you will need to parse the string back into a date/datetime object, which is not very appealing to do.
As a general good practice: the way you store data should be agnostic to the way you present it, when possible.
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 data stored on a SQL Server in a country that is GMT + 2. So for instance, a DateTime value is something like 1/1/1800 12:00:00 AM.
Now, I have a C# console app, that is running on a server in UK. The C# is reading those values from the remote database. However, the date received are 2 hours less, for instance: 31/12/1799 22:00:00.
I changed culture to en-US, the only thing that changed was the printing of 10:00:00 PM instead of 22:00:00
Any idea why the date values are being "auto-converted" to locale timezone instead of keeping the values as is?
Thank you
Regards
The problem you're experiencing is not related to the culture on your computer, it is related to a conversion of timezones.
When initializing the connection - there's a negotiation happening between you and the server that tells the server the time zone of your location, and does the conversion for the communication automatically for you.
First, try to understand what is stored in the DBMS, and what you want it to store.
Maybe you need to change your DateTime type to one that considers timezones: for example: http://blogs.msdn.com/b/sqlprogrammability/archive/2008/03/18/using-time-zone-data-in-sql-server-2008.aspx
If you don't want to have timezone "adjustments" try to synchronize the DBMS session to be on the same timezone (between your client and the SQL Server) - so no conversions would occur.
There are two things you shouldn't confuse here: (1) how the data is stored in the database; (2) how it is displayed. The database should be storing the information in a timezone-agnostic way; it's up to you how you display it.
This means that there are two things that might be going wrong. Either it's being stored wrong, because the application putting things into the database is not correctly interpreting the date/time that it wants to store, or, more likely, you're converting to local time when you display it.
I'm not sure how you're doing the conversion, but lots of date/time functions will use the default locale if you don't specify one. They will allow you to specify a locale if you want to, though.
If I were you, I'd have a look at the raw data in the database to see whether that's correct.
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.