Cor Ligthert said:
The invarianculture in case of datetime is associated with the English
Language where you can have dependend of the culture june 15 and 15 june.
The invariant culture is invariant by definition and it's unique, which
means that it doesn't suffer from the problems other cultures suffer from.
If June, 15th is persisted using the invariant culture and later read using
the invariant culture, it will always result in June, 15th.
This makes it possible to do a dataparse.time(date in written words) for
both culture systems in the English language.
Why would you want to mix up different cultures?
'CultureInfo.InvariantCulture' has (by definition) as much to do with 'de'
as with 'en'. It's simply a separate culture.
Dates written in German needs the parameter in that case that it is in the
German culture, however if that is the local setting than Nothing is more
than enough (while invariantculture will than have the same effect as
nothing because the culture is already German).
?!? 'InvariantCulture' is a completely independent culture. It has the
same semantics on all systems and thus will never be the same as another
culture.
The system does not automaticly recognise that by instance "1/12/2006" is
one time 12 december and anoter time januari 12 how much time you write
that it is an invariant culture.
If you have a 'Date' variable representing '#1/12/2006#' (written as VB date
literal) and persist it using the invariant culture and later use the
invariant culture to read the persisted value the resulting 'Date' object
will have the value '#1/12/2006#'. One doesn't have to care about and know
the format used to persist the date using the invariant culture. The
invariant culture's main purpose is to make exchange of data between
different systems running with different culture settings easier by removing
any ambiguities potentially caused by different culture settings.