Simple String To Date Time

  • Thread starter Thread starter Doug
  • Start date Start date
D

Doug

I can't imagine this is that hard but I'm sure having a struggle
finding it. How do I convert a value like "111403" do a DateTime
variable in DotNet (i.e. 11/14/2003)?
 
Doug said:
I can't imagine this is that hard but I'm sure having a struggle
finding it. How do I convert a value like "111403" do a DateTime
variable in DotNet (i.e. 11/14/2003)?
Click to expand...

Use DateTime.ParseExact, specifying a date format. eg:

DateTime dt = DateTime.ParseExact("MMddyyyy",
CultureInfo.InvariantCulture);
 
Jon Skeet said:
Use DateTime.ParseExact, specifying a date format. eg:

DateTime dt = DateTime.ParseExact("MMddyyyy",
CultureInfo.InvariantCulture);
Click to expand...

Whoops - forgot the all important input string!

DateTime dt = DateTime.ParseExact (input, "MMddyyyy",
CultureInfo.InvariantCulture);
 
Hi
I got "String.FormatException - String was not recognised as a valid
DateTime" when i used this DateTime.ParseExact .
Doug, i suggest you to use ur own logic in the code to split the string
"111403" to "11/14/2003"
 
Santi,

Did you try it with
DateTime dt = DateTime.ParseExact (input, "MMddyy",
CultureInfo.InvariantCulture);

In my opinion a very little obvious typo from Jon,


Cor
 
Santhi,
I tried it works for some strings only.If i give "11403" it fails..
Click to expand...
I thought that you were asking for
"111403" this one you show now, I did not see,

Can you exlain to me what
010101 than means and what
1111 than will be

Cor
 
010101 means 01/01/2001
1111 will be 1/1/2011

Cor Ligthert said:
Santhi,

I thought that you were asking for
"111403" this one you show now, I did not see,

Can you exlain to me what
010101 than means and what
1111 than will be

Cor
Click to expand...
 
Cor Ligthert said:
Santi,


Why not
01/11/2001
or
11/01/2001

Cor
Click to expand...

Cor
1111 cant be 01/11/2001 or 11/01/2001 ...
we will always represent year with 2 digits..like 2/2/00,10/2/00,12/30/00
not as 2/2/0 or 10/2/0 .
 
DateTime dt = DateTime.ParseExact (input, "MMddyy",
CultureInfo.InvariantCulture);

This works for what I need. My code won't be going outside the English
language so I should be okay.
 
Now, just to satisfy my curiosity, I tested it and it will read 00 - 29
for the year as being in the 2000's and 30-99 as being in the 1900's.
I'm not all that sure I'll be around in 2030 for it to matter that much
to me personally ...:) but I am curious about it and the implications
of just assuming that will work correctly?
 
Doug,

I knew that it was working, however Jon gives this answer for ever, if you
see the link that I provided than it tells that it is only for the English
language area.

92% of the world is not in that area.

So I am curious why he does it and what can be the reason of that, AFAIK can
there as well be used nothing/null and than it works everywhere.

However I wrote AFAIK so I am curious about Jon his opinion.

Cor
 
Cor Ligthert said:
Why are you using so consequently the Culture.InvariantCulture, are you sure
that it outside the English language area does not give problems?
Click to expand...

If the format is using ASCII digits (as opposed to Arabic digits etc)
then yes, I am sure it won't give any problems. The format given seems
to me to be culturally invariant, so using the invariant culture is the
right thing to do.
 
Santhi Maadhaven said:
1111 cant be 01/11/2001 or 11/01/2001 ...
we will always represent year with 2 digits..like 2/2/00,10/2/00,12/30/00
not as 2/2/0 or 10/2/0 .
Click to expand...

Cor gave another example of where it would be ambiguous. Why do you
think it's worth making the year part always 2 digits (and why not
four?) but not the month and day parts?

To be honest, I think you're asking for trouble using that kind of
ambiguous format.
 
Jon,
If the format is using ASCII digits (as opposed to Arabic digits etc)
then yes, I am sure it won't give any problems. The format given seems
to me to be culturally invariant, so using the invariant culture is the
right thing to do.
Click to expand...
Do they now use in Britain other ciphers (digits), on the continent we use
(West) Arabic characters to represent a cipher (digit). I did not see that
yet on BBC, that shows its pages still with (West) Arabic digits.

:-)


This is the first statement on the page I have showed you.

----------------------------------------
The CultureInfo.InvariantCulture property is neither a neutral nor a
specific culture. It is a third type of culture that is culture-insensitive.
It is associated with the English language but not with a country or region.
You can use InvariantCulture in almost any method in the
System.Globalization namespace that requires a culture. However, you should
use the invariant culture only for processes that require
culture-independent results, such as system services. In other cases, it
produces results that might be linguistically incorrect or culturally
inappropriate.
 
Do they now use in Britain other ciphers (digits), on the continent we use
(West) Arabic characters to represent a cipher (digit). I did not see that
yet on BBC, that shows its pages still with (West) Arabic digits.
Click to expand...

Sorry, yes, I mis-spoke. I picked Arabic as a random example, and it's
a very bad one :)

I wouldn't be surprised if, say, the Chinese used different characters
for digits - but I very much doubt that the format specified should
accept those characters *or* reject ASCII digits when presented with
them in China.

The fact that the invariant culture is English is entirely irrelevant
here.
This is the first statement on the page I have showed you.

----------------------------------------
The CultureInfo.InvariantCulture property is neither a neutral nor a
specific culture. It is a third type of culture that is culture-insensitive.
It is associated with the English language but not with a country or region.
You can use InvariantCulture in almost any method in the
System.Globalization namespace that requires a culture. However, you should
use the invariant culture only for processes that require
culture-independent results, such as system services. In other cases, it
produces results that might be linguistically incorrect or culturally
inappropriate.

----------------------------------------
Click to expand...

And that makes perfect sense with what I did - I don't see that this
conversion *should* be dependent on the culture of the system.

Could you give an example where you'd *want* the specified format to
give different results in different cultures?
 
Back
Top