dateTime Manupulations

[Jay B. Harlow [MVP - Outlook]]

Cor,

When you and Jay want to hard code a dateformat in a program, it is fine,
I keep telling in this newsgroup to use as posible as can the
globalization settings.

If you read the original posts, they both state directly or indirectly a
"hard coded date format", we (Herfried and I) are not suggesting they do
this, we (Herfried and I) are suggesting if they do this do it in the
"correct" manner, which is DateTime.ParseExact.

You seem to be suggesting that CDate is the only way and to get it to work,
change the CurrentCulture.

I am seriously questioning, why you would change the CurrentCulture to
format dates. You offered an explanation, to which I still seriously
question why you would think this way.

You haven't really offered any real explanation that I can follow...

I hope you will understand if I don't respond to you on this matter any
more, its not that I cannot speak for myself, its that its too tiring and
life is too precious to try and explain it to you. :-|

I would ask you wait until tomorrow before responding, instead "walk in
another mans shoe" & try the samples we have given, and why we would offer
our advice.

Thanks
Jay

 

[Cor Ligthert]

Herfried,

That's something different we are not talking about, because the OP
doesn't need that. Jay gave an excellent sample where parsing date
strings in a specific format is a requirement:

I did not discuss that, because that was for me not the primairy question, I
am from Holland you know, we are for ages dealing with very much cultures,
he asked me in a way if I did understand what different cultures mean.
Probably you do not know what that means when somebody ask that to a
Dutchman. Therefore I found it better not to answer.

However as I stated in this thread, even than is it better to pack his
example in a class, and than do all date time or other culture and whatever
handling. That will make it much easier and better to maintanance everything
than by doing that inline somewhat hidden in a program. He did not answer
that as well.

This would be an example.

Get the culture settings from whatever document from whatever page by
instance using the clientcertificate.

Set the globalization.culture with that
Do all the handling with the XML document
Set the globalization setting back to the normal used

This gives me more the idea of good program than inline setting of all the
date formats.

However that is not the point where we are discussing about. We are
discussing that I say that it is good to use the globalization settings as
much as possible and to avoid hard coded date time formats as you have
statted and from what I get the idea Jay is supporting you.

Cor

 

[Herfried K. Wagner [MVP]]

And what is wrong with my answer than packed in a sample
that would work in every culture setting.

It would not work with every culture setting... See below...

MessageBox.Show(CDate("01-JUNE-2004 11:59 PM").Addminutes(1).ToString)

\\\
Imports System.Globalization
Imports System.Threading
..
..
..

' Fake the user's culture settings...
Dim ci As New CultureInfo("en-US")
ci.DateTimeFormat.MonthNames = _
New String() { _
"JUNE", _
"B", _
"C", _
"D", _
"E", _
"F", _
"G", _
"H", _
"I", _
"J", _
"K", _
"L", _
"M" _
}
Thread.CurrentThread.CurrentCulture = ci
..
..
..
MsgBox(CDate("01-JUNE-2004 11:59 PM").AddMinutes(1).ToString())
///

The result will be a date in January 2004, which is not what the user
expects...

The best solution is using 'DateTime.ParseExact' in combination with
specifying the date format pattern + the invariant culture.

 

[Herfried K. Wagner [MVP]]

Set the globalization.culture with that
Do all the handling with the XML document
Set the globalization setting back to the normal used

This gives me more the idea of good program than inline setting of all the
date formats.

I doubt that this is the best solution. Imagine your class throwing an
exception and not setting back the current culture, for some reason. Many
methods accept a format information or culture information object in order
to use a specific format information for doing their job. All of that can
be done without actually changing the culture of the thread the routine is
running in.

However that is not the point where we are discussing about. We are
discussing that I say that it is good to use the globalization settings as
much as possible

I agree, and I think that Jay agrees to that too, but that's not always a
viable option (see Jay's sample with exchanging XML files).

 

[Cor Ligthert]

Jay,
..

I answered you in the form of questions earlier, hoping you would think
for a hour or so & come to the same conclusions as the rest of us.

It seems that you can give only this kind of abusing answers to me telling
what I do not know. A kind of writting what is beneath my level so you have
no problem with that from me.

You are avoiding real answers on concrete questions, and now even
misquoting me by deleting the sample.

What is wrong with an concrete answer on my question, do you have to agree
with that sample maybe?

As I said in the other thread which you never answered like probably this of
course, I find the globalization one of the best things from dotNet.

The only thing you tell in this thread is that you and other MVP's know it
better and that you do not agree with me, where I say that the globalization
settings should be used. And because of that you are telling that the date
and time where it is used should be hard formated.

Cor

 

[Cor Ligthert]

I have said in all those threads that there was nowhere showed that there
should be a culture change in the dates. When I write to you that my
datestring is in the dd-MM-yy format, does that than means for you that you
have to give me directly the sample to change it into the US date.

I have nowhere written for the rest in the previous message, what you said
that I wrote, that comes from your mind not mine.

I have given you an example in a previous message in this thread, why using
the culture settings was better, as this bellow you did probalby not take
the time to read that.

This is in the message you was now answering.

When it was an obvious question about a culture change from a date, than I
would have said nothing about using the datetime.parse or any other command
that was sufficient.

And when you don't understand something from my messages, ask first what you
don't understand before you give an answer.

Cor

 

[Rangi Keen]

This and the previous discussion on date parsing have been very amusing. I
think there must be some miscommunication happening somewhere (perhaps a
language issue), but I agree that DateTime.ParseExact would be the best
method in both these cases.