4

I've been looking for information on Internet about this optional parameter CultureInfo.InvariantCulture when formatting in .NET

These articles explains about it: What does cultureinfo invariantculture mean , What is the invariant culture. But it's still not clear for me.

I want to manage and save a datetime variable as this format 'yyyyMMdd' and I formatted it like this:

DateTime localDateTime = DateTime.Today; //> 2016-02-10 12:33
string formattedDateTime = localDateTime.ToString("yyyyMMdd"); //> 20160210

It is suppossed to have a varchar column in db with a length of 8. But in a specific case it started to save 7 chars. I'm waiting to get access to our client's domain to check the saved format.

However, each user can set no matter what culture in the system (e.g. "en", "es", "fr"), so even if the method ToString which is forced to format like this "YYYYMMDD", do I need to set the invariant culture? If not, I could risk to have my datetime in string with another format? Does the regional configuration in database server matter?

This is that I'm attempting to do right now, but not sure if this will fix the problem after we check in tests:

DateTime localDateTime = DateTime.Today;
string formattedDateTime = localDateTime.ToString("yyyyMMdd", CultureInfo.InvariantCulture); //> 20160210

This is another scope, if I need to build my variable from database and save it in a stored procedure, I'm doing this:

CONVERT(varchar, getdate(), 112) --ISO for yyyymmdd

EDIT:

We did some tests:

DateTime currentDateTime = dateParameter; // 10/2/16 12:33 PM
string dateParameterAsString = dateParameter.ToString(); // "10/2/16 12:33 PM"
string formattedIdentifier = dateParameter.ToString(System.Globalization.CultureInfo.InvariantCulture); // "02/10/2016 12:33:00"
string formattedIdentifier2 = dateParamter.ToString("yyyyMMdd"); // "20160218"
string formattedIdentifier3 = dateParamter.ToString("yyyyMMdd", System.Globalization.CultureInfo.InvariantCulture); // "20160218"
Community
  • 1
  • 1
Maximus Decimus
  • 4,901
  • 22
  • 67
  • 95
  • 3
    Do yourself a favor and don't store datetime information as character data. Store it as date or datetime. – Sean Lange Feb 10 '16 at 19:57
  • 1
    If you're trying to do the conversion purely for building a SQL string, you'd be better off using `SqlParameter`s – Rowland Shaw Feb 10 '16 at 19:57
  • @SeanLange In fact we are using a datime column in db for this datetime value. However, according to some evaluations in our processes, we are saving this value as identifier for biz purposes in another column. – Maximus Decimus Feb 10 '16 at 20:00
  • YYYMMDD is not a correct format string to convert a datetime to a string. (_yyyyMMdd_) and with this format you don't need any CultureInfo, but go back to comment #1 please – Steve Feb 10 '16 at 20:00
  • culture determines the order (month or day first) separators or the actually language to display the month names in for default and standard formats. When you specify a custom one that does not use separators or the name of the month then culture really doesn't come into play. – juharr Feb 10 '16 at 20:00
  • @Steve Sorry. It's a typo. Corrected! – Maximus Decimus Feb 10 '16 at 20:01
  • It wouldn't surprise me at all if the reason you got 7 characters was due to using a non-Gregorian calendar. – Eric MSFT Feb 12 '16 at 18:32
  • @SeanLange sqlite doesnt support datetime. you have no other option than string – Emil Jun 29 '17 at 22:16
  • 1
    @batmaci this question is clearly marked with sql server which does have a datetime datatype. The fact that sqlite doesn't is a clear indication that it is a technology I would run away from as fast as possible. What a massive shortcoming. – Sean Lange Jun 30 '17 at 13:34
  • @SeanLange it is a very unfortunate technology but it doesnt leave any other option for mobile development if someone wants a local database – Emil Jun 30 '17 at 13:36

2 Answers2

3

For your particular use case, specifying the culture explicitly as CultureInfo.InvariantCulture isn't absolutely necessary.

For the format string "yyyyMMdd", all of the components will output just integer characters, and happen to be unaffected by culture. Using CultureInfo.InvariantCulture might be a small performance improvement (avoids having to lookup the current thread's culture), and isn't a bad thing to get in the habit of if you want to develop against very specific information. It would only be an issue if you were using "ddd" or anything else that involves the name of the month, day, etc. (or simply using .ToString() without parameters, which would have the entire thing determined by the current thread's culture)

That said, let's look at the other issue here: you're creating strings to store in your database. Why is this being done here rather than in the presentation layer? Are you not using parameterized queries?

Please, please please use parameterized queries. See How and Why to Use Parameterized Queries

willaien
  • 2,647
  • 15
  • 24
  • Thanks for your valuable answer. It's not calculated at presentation layer. It's done within a service library which receives all the parameters and once calculated, all the data is managed with a ORM library that uses SqlParameters inside. We're analyzing at this moment the service method which performs this calculation. I'm afraid that in cases where the datetime is 2016-02-01, it is being saved as 201621 (6 chars) – Maximus Decimus Feb 10 '16 at 20:30
1

As you mentioned in comments, you have a datetime field and you are going to have a character representation of that. In this case I suggest you use a computed column and do everything in database level.

FLICKER
  • 6,439
  • 4
  • 45
  • 75