converting date to long and short, doesn't work in some systems.

[MaestroRage]

My team and I are developing a scheduler program in .NET that reads from a database and spits out information on a datagridviewer. You can add/delete/edit etc, but for whatever reason 2 of the 3 members (including myself) displays the date differently. The other member who not only has the EXACT same laptop model as me, but bought it the same week, displays his date time differently.

Because of this we developed our system in a way that only works in ours. Is there a way to change our date settings to conform to how the school has it? Our first pass cost us big marks because nothing displays on the profs computer, who complies with a different date setting then ours.

 

[jmcilhinney]

The date settings should be irrelevant. You're talking about the format of string representations of dates. That makes no difference to the date itself. Are these different dates?

1969-Jun-19
June 19, 1969

Of course not. They're simply two different string representations of the same date.

Now, in your VB code you should ALWAYS be working with binary Date objects. You should be saving the data to a datetime column (or equivalent for your database) so everything is binary. Binary dates are stored as numbers so format is no issue.

The only time format is an issue is when you want to represent a date as a string. In that case you should just use the default format for the current system. For instance, if I take the date above and do this:

MessageBox.Show(myDate.ToShortDateString())

what the user actually sees depends on their Windows Regional Settings. A user in the US will most likely see "6/19/1969" because that's the default short date format in the US. A user here in Australia will most likely see "19/06/1969" because that's our default short date format. It's still exactly the same date but each user is seeing what they expect to see based on their location.

Now, you might think that it's bad for different users to see different things but it's actually very good. A user will generally assume that any dates displayed by your app are in the format determined by their Regional Settings. If your app displays "1/02/2000" then an American will assume that that's January 2nd, while an Australian will assume that it's February 1st. One of them will be wrong and that's very, very bad. You should display dates in whatever format the user expects to see, which means just allowing the system to use default format.

Now, if you're receiving input from the user then the same rules apply. Generally you should use a DateTimePicker to gather date input. You can set the Format to Short and the control will assume that the user is entering a value consistent with their Regional Settings.

If you decide that you do want to use a specific date format regardless of Regional Settings then it's irresponsible to use one that isn't obvious to all. That means using letters instead of numbers for the month. The most common choices would be "d-MMM-yyyy" and "yyyy-MMM-dd". The three Ms for the month indicate that the three letter abbreviation be used.

 

[cjard]

Note that you should keep things as dates wherever possible. Do not do conversions to string yourself, using a forced format. Use a datepicker to have the user pick a date, store it in a date variable, upload it into a date column in a database using a parameterised query that has the relevant parameter set to be a date datatype... be consistent, store as dates and use the default regional settings for showing on screen, as a string, at the last minute. Do not store a date in string form!