Is there a way to use user's culture to localize the Range Validator for date? I am looking for a good way to validate date and avoiding to provide a fix format (e.g.: do a dd/mm/yyyy using Regular Expression Validator)
Use the Date.TryParseExact() method, consulting the documentation.
Use members of the returned My.Application.Culture.CurrentCulture.DateTimeFormat object, which is of class System.Globalization.DateTimeFormatInfo, to retrieve the date formats for the current culture (there are several formats for every culture, such as long format and short format...).
This will be something closest to what I want actually.
Getting user's language preference based on language settings:
userLanguage = Request.UserLanguages[0];
Get ShortDatePattern base on language:
new CultureInfo(userLanguage).DateTimeFormat.ShortDatePattern;
From here I will use the pattern to validate user's input and to display the required format on the page.
Related
In the First overload of ParseExact method
public static DateTime ParseExact (string s, string format, IFormatProvider provider);
according to Microsoft:
If format is a custom format pattern that does not include date or time separators (such as "yyyyMMddHHmm"), use the invariant culture for the provider parameter and the widest form of each custom format specifier. For example, if you want to specify hours in the format pattern, specify the wider form, "HH", instead of the narrower form, "H".
In particular if we use stander format pattern we could use any other cultures
what is the really purpose of using invariant culture and widest custom specifier if we use custom format pattern that does not include date or time separators if we use?
The purpose of InvariantCulture is to have a well-known way to format dates and numbers, that does not depend on the system or user locale.
You should use it every time you format something that is not meant to be parsed by humans. For example in a JSON or XML file you want to store the date in ISO format so there is no ambiguity. On the other hand if you display the date on the screen, you generally respect the user's choice of culture and display it in the preferred way.
If you use a custom format, then it would surely be good if the resulting string can be parsed back into the exact same date and time. In order to do that without separators you have to use fixed length strings for each component.
// omitting CultureInfo.InvariantCulture for brevity
var dt = new DateTime(2018,1,2,3,45,6);
dt.ToString("yyyyMMddHHmmss") // returns "20180102034506"
dt.ToString("yyyyMdHms") // returns "2018123456"
You can easily see that the second one is not unique, i.e. there are other dates which will return the same string. In order to avoid that you use the wider form of each component.
the real purpose of invariant culture is taken taken from a an answer in this question, as it describes it's purpose best:
Not all cultures use the same format for dates and decimal / currency
values.
This will matter for you when you are converting input values (read)
that are stored as strings to DateTime, float, double or decimal. It
will also matter if you try to format the aforementioned data types to
strings (write) for display or storage.
If you know what specific culture that your dates and decimal /
currency values will be in ahead of time, you can use that specific
CultureInfo property (i.e. CultureInfo("en-GB")). For example if you
expect a user input.
The CultureInfo.InvariantCulture property is used if you are
formatting or parsing a string that should be parseable by a piece of
software independent of the user's local settings.
To sum this up, the invariant culture will help with conversions be a string stored to float, decimal or asDateTime, it is here also to help when you are trying to format or parse a string that should be parseable by a piece of software independent of the user's local settings, as the quote said and that is what
widest custom specifier
means by that.
I want to be able to check against the environments timezone settings and if its not a US timezone then I will handle the datetime with a more global format. For example. I have a user in America their settings is MM-DD-YYYY now if I have another user in Canada they want to see DD-MM-YYYY but instead of just giving them different versions I would rather have some logic that grabs the timezone and compares it against something and then that determines how the datetime will be handled.
if(System.TimeZone.StandardTime = US)
{
objOrderEntryItemUsageReport.VarShipDate = Convert.ToDateTime(datpkrShipDate.Value).ToString("MM/DD/YYYY");
}
else
{
objOrderEntryItemUsageReport.VarShipDate = Convert.ToDateTime(datpkrShipDate.Value).ToString("DD/MM/YYYY");
I just don't know the best way to check the environments timezone settings and even how to compare it to see if its a US timezone?
Would I need to create a dictionary with the American timezones in it and then do a while loop through that dictionary to see if the current timezone matches and if not then handle it like an international user?
The user's time zone and the user's culture are entirely separate matters.
It's not clear where this code is running, but basically you want to use the appropriate CultureInfo, and then you can use DateTime.TryParse specifying the culture. You can use TryParseExact specifying a standard format of d for "short date format". (Likewise for calls to ToString... just pass in the culture and a format of d.)
Alternatively - and preferably - use a DateTimePicker so you don't need to parse the value at all. (Given your names, it's possible that you're already using a DateTimePicker, so it's unclear why you're calling Convert.ToDateTime - the Value property is already of type DateTime.
Then, don't convert it to a string later either - your VarShipDate property shouldn't be a string property, it should be a DateTime property. That's what you're trying to represent, after all. Avoid string conversions as far as you possibly can. They are error-prone, culturally sensitive, and basically full of potential fail.
Additionally, I would strongly advise against using System.TimeZone - use System.TimeZoneInfo, which is effectively the replacement for TimeZone.
I have a datetime in this format "Wednesday, December 04, 2013". I want to translate it to different cultures at runtime so that i am able to store that in database according to culture.
This is my code:
dysMngmt.Day = curntDate.ToString("D");
The one line code above is getting the day.
So,please help me.
You can use the second argument of the ToString function, which enables you to pick a culture you see fit:
curntDate.ToString("D", CultureInfo.GetCultureInfo("en-US"))
As a side note, why are you saving the date in your database as a string? Why not use a native date date type? It will take less space and allow you comparisons etc., and then you'd just use the currect culture when reading it out of the database.
Unless you have a very good reason for handling the culture of each date seperatly within the application you should set this at the application level so that the default ToString() works with your intended culture.
http://support.microsoft.com/kb/306162
Also, you should probably also not store dates as text in your database.
Is it good approach in the model binder use the code like this:
TryParseDate(result.AttemptedValue, format, out parsedDate)
And then "format" is a variable with different (customer specific) date format. Like 12/31/2013 or 31.12.2013 or other ones.
I have big problem with the format binding because if user puts the date with only 1 digit like: 1/1/2014 it will not parse because in the "format" value allowed formats: dd/MM/yyyy
I know that it is possible to resolve by replacing this format to d/M/yyyy and then it works for both case, but is it good approach or it is dangerous?
Thank you in advance!
I would recommend leaving the default model binder to do its work, it does a pretty good job of it and will deal with localization issues (ie. different date formats for different locales) for you.
Consider that there will always be restrictions on how a user can enter a date (you don't allow them to enter yyyy-MM-dd for example, even though it is a valid date format). Your custom binder code won't change that because it supplies a format.
I'd suggest that your goal should be to permit users to enter dates in the format that would be most usual for them (eg. dd/MM/yyyy in UK or Spain, MM/dd/yyyy in US etc). That will deal with the majority of cases. If you need to cater for users in different locales, the default model binder will do it all for you, so long as you set the thread culture for the user session:
string cultureCode = "en-GB"; //retrieve eg. from user profile
Thread.CurrentThread.CurrentCulture = new CultureInfo(cultureCode)
If you want to help users who are inputting dates in other formats, simply put a hint on your page that explains the expected format.
If you really must accept multiple formats per locale, you will need to write a custom model binder, and might want to try passing an array of acceptable formats to it for each locale that you deal with.
How can I get today's date in M/d/yyyy format irrespective of system format of date using C#?
DateTime.Now.Tostring('M/d/yyyy')
is working only if the system date is in format dd/MM/yyyy or M/dd/yyyy but is not working in case yyyy-MM-dd format.
Eg:
if system date is 2013-06-26 then DateTime.Now.Tostring('M/d/yyyy') is converting the date into 06-26-2013 but not in 06/26/2013
Use CultureInfo.InvariantCulture to enforce / as date separator:
DateTime.Now.ToString("M/d/yyyy", CultureInfo.InvariantCulture)
Ideone
Looks like you just need to use CultureInfo.InvariantCulture as a second parameter in your .ToString method.
Console.WriteLine(DateTime.Now.ToString("M/d/yyyy", CultureInfo.InvariantCulture));
Using the invariant culture is the correct solution if you always want the same DateTime to produce the exact same string on multiple systems (or even on the same system due to culture changes). However, be aware that if this is user-visible, you're giving up the possibility of internationalization (for instance, if you display day or month names, they will be in English regardless of what language the user speaks). To only ensure that slashes are not replaced with another date separator, use single quotation marks:
DateTime.Now.Tostring("M'/'d'/'yyyy");
Edit:
Also, if your users are using different date formats, there's a good chance they're also using different time zones. If this DateTime needs to make sense across multiple systems, consider using DateTime.UtcNow. This will also protect you against potential bugs due to a user changing their time zone (when travelling, say) or daylight saving/summer time beginning/ending. If you're just displaying the string to the user at the current instance and not persisting it, DateTime.Now is probably what you want. In that case, however, I'd question why you're trying to mess with the format they've chosen.
Like this:
DateTime.Now.Tostring("M'/'d'/'yyyy");
The apostrofe forces the ToString() method to use the delimiter that you specified.
However, I would let the user choose a culture and use that cultures default formatting instead.