Cannot parse an en-US date on a non-en-US system!

J

Jon Davis

I have put my users through so much crap with this bug it is an absolute
shame.

I have a product that reads/writes RSS 2.0 documents, among other things.
The RSS 2.0 spec mandates an en-US style of date formatting (RFC 822). I
have been using a variation of RFC 1123 (just change the time zone to an
offset, i.e. "-0800"). It seems to be writing okay, but it's failing to
parse.

I've tried changing the regional & language settings in my Windows XP
control panel so that I could test, but after getting it to work that way, a
guy from Pakistan (I think?) is still getting date parsing problems.

Here's what I've got. See ParseDateTime() below.



/// <summary>
/// Currently, this method simply calls DateToRFC1123String(),
/// but then changes the time zone to "+/-####", i.e. "-0700".
/// </summary>
public static string DateToRFC822String(DateTime dt, bool
fromLocalTimeZone) {
string dts = DateToRFC1123String(dt, false);
if (fromLocalTimeZone) {
string offset = MiscUtil.SysDTOffset.ToString();
offset = offset.Replace(":", "").Replace(" ", "");
if (offset.Substring(0, 1) != "-") {
if (offset.Substring(0, 1) == "+") {
offset = offset.Substring(0, 5);
} else {
offset = "+" + offset.Substring(0, 4);
}
} else {
offset = offset.Substring(0, 5);
}
dts = dts.Replace("GMT", offset);
}
return dts;
}

public static TimeSpan SysDTOffset {
get {
return System.TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Now);
}
}

/// <summary>
/// Converts a time zone (e.g. "PST") to an offset string (e.g. "-0700").
/// </summary>
/// <param name="tz">The time zone to convert.</param>
/// <returns>The offset string (e.g. "-0700").</returns>
public static string TimeZoneToOffset(string tz) {
tz = tz.ToUpper().Trim()
.Replace("PACIFIC", "PST")
.Replace("MOUNTAIN", "MST")
.Replace("CENTRAL", "CST")
.Replace("EASTERN", "EST");
for (int i=0; i<TimeZones.Length; i++) {
if (((string)((string[])TimeZones.GetValue(i)).GetValue(0)) == tz) {
return ((string)((string[])TimeZones.GetValue(i)).GetValue(1));
}
}
return
System.TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Now).ToString()
.Replace(":", "").Substring(0, 5);
}

public static string OffsetToTimeZone(string offset) {
foreach (string[] tz in TimeZones) {
if (((string)tz.GetValue(1)) == offset) {
return (string)tz.GetValue(0);
}
}
return "GMT";
}

public static string OffsetToTimeZone(string offset, bool
isDaylightSavings) {
foreach (string[] tz in TimeZones) {
if (((string)tz.GetValue(1)) == offset) {
string tzs = (string)tz.GetValue(0);
if (isDaylightSavings) {
switch (tzs) {
case "PDT":
return tzs;
case "MDT":
return tzs;
case "CDT":
return tzs;
case "EDT":
return tzs;
case "MST":
return "PDT";
case "CST":
return "MDT";
case "EST":
return "CDT";
default:
return tzs;
}
} else {
return tzs;
}
//return;
//return (string)tz.GetValue(0);
}
}
return "GMT";
}

public static string DateToRFC1123String(DateTime dt, bool
fromLocalTimeZone) {
if (fromLocalTimeZone) {
dt = dt.ToUniversalTime();
}
System.Globalization.CultureInfo ci = new
System.Globalization.CultureInfo("en-US", false);
string ret = dt.ToString(ci.DateTimeFormat.RFC1123Pattern, ci);
return ret;
}


/// <summary>
/// Parses dates with time zones in the following formats:
/// "Thu, 17 Jul 2003 12:35:18 PST",
/// "Thu, 17 Jul 2003 12:35:18 -0700".
/// Converts the time to the local time zone.
/// </summary>
/// <param name="dateTime">The date/time to parse.</param>
/// <returns>A DateTime object</returns>
public static DateTime ParseDateTime(string dateTime) {
System.Globalization.CultureInfo ci = null;
try {
ci = new System.Globalization.CultureInfo("en-US", false);
return DateTime.Parse(dateTime,
ci,
System.Globalization.DateTimeStyles.AllowWhiteSpaces);
} catch (FormatException fex0) {
try {
fex0=fex0; // ignore
return DateTime.Parse(dateTime,
System.Globalization.DateTimeFormatInfo.InvariantInfo,
System.Globalization.DateTimeStyles.AllowWhiteSpaces);

} catch (FormatException fex) {
try {
try {
string iso8601_date = dateTime;
ci = new System.Globalization.CultureInfo("en-US", false);
return DateTime.ParseExact(
iso8601_date,
ci.DateTimeFormat.SortableDateTimePattern,
ci.DateTimeFormat);
} catch {}
string loc = fex.Message.Substring(fex.Message.LastIndexOf(" "));
loc = loc.Substring(0, loc.LastIndexOf("."));
string tz = "";
if (loc.Trim() == "DateTime") {
tz = dateTime.Substring(dateTime.LastIndexOf(" ")).Trim();
dateTime = dateTime.Substring(0, dateTime.Length - tz.Length);
} else {
try {
int iLoc = int.Parse(loc);
tz = dateTime.Substring(iLoc);
tz = TimeZoneToOffset(tz);
dateTime = dateTime.Substring(0, iLoc);
} catch {
}
}
ci = new System.Globalization.CultureInfo("en-US", false);
DateTime ret = DateTime.Parse(dateTime,
ci,
System.Globalization.DateTimeStyles.AllowWhiteSpaces);

// offset for time zone
if (tz.Length > 0) {
try {
if (tz.Length == 4 && tz.Substring(0, 1) != "-") {
try {
int.Parse(tz.Substring(0, 1));
tz = "+" + tz;
} catch {
}
}
if (tz.Length == 5 && tz.Substring(0, 1) == "-" ||
tz.Length == 5 && tz.Substring(0, 1) == "+") {
try {
int h = int.Parse(tz.Substring(1, 2));
int m = int.Parse(tz.Substring(3, 2));
if (tz.Substring(0, 1) == "-") {
ret = ret.AddHours((h * -1) - SysDTOffset.Hours);
ret = ret.AddMinutes((m * -1) - SysDTOffset.Minutes);
} else {
ret = ret.AddHours(h - SysDTOffset.Hours);
ret = ret.AddMinutes(m - SysDTOffset.Minutes);
}
} catch {
}
}
} catch {}
}

return ret;
} catch {
return new DateTime(0);
}
}
}
}

/// <summary>
/// An array of time zones
/// (e.g. new string[] {"PST", "-0700", "(US) Pacific Standard"}).
/// </summary>
public static string[][] TimeZones = new string[][] {
new string[] {"ACDT", "+1030", "Australian Central Daylight"},
new string[] {"ACST", "+0930", "Australian Central Standard"},
new string[] {"ADT", "-0300", "(US) Atlantic Daylight"},
new string[] {"AEDT", "+1100", "Australian East Daylight"},
new string[] {"AEST", "+1000", "Australian East Standard"},
new string[] {"AHDT", "-0900", "AHDT"},
new string[] {"AHST", "-1000", "AHST"},
new string[] {"AST", "-0400", "(US) Atlantic Standard"},
new string[] {"AT", "-0200", "Azores"},
new string[] {"AWDT", "+0900", "Australian West Daylight"},
new string[] {"AWST", "+0800", "Australian West Standard"},
new string[] {"BAT", "+0300", "Bhagdad"},
new string[] {"BDST", "+0200", "British Double Summer"},
new string[] {"BET", "-1100", "Bering Standard"},
new string[] {"BST", "-0300", "Brazil Standard"},
new string[] {"BT", "+0300", "Baghdad"},
new string[] {"BZT2", "-0300", "Brazil Zone 2"},
new string[] {"CADT", "+1030", "Central Australian Daylight"},
new string[] {"CAST", "+0930", "Central Australian Standard"},
new string[] {"CAT", "-1000", "Central Alaska"},
new string[] {"CCT", "+0800", "China Coast"},
new string[] {"CDT", "-0500", "(US) Central Daylight"},
new string[] {"CED", "+0200", "Central European Daylight"},
new string[] {"CET", "+0100", "Central European"},
new string[] {"CST", "-0600", "(US) Central Standard"},
new string[] {"EAST", "+1000", "Eastern Australian Standard"},
new string[] {"EDT", "-0400", "(US) Eastern Daylight"},
new string[] {"EED", "+0300", "Eastern European Daylight"},
new string[] {"EET", "+0200", "Eastern Europe"},
new string[] {"EEST", "+0300", "Eastern Europe Summer"},
new string[] {"EST", "-0500", "(US) Eastern Standard"},
new string[] {"FST", "+0200", "French Summer"},
new string[] {"FWT", "+0100", "French Winter"},
new string[] {"GMT", "-0000", "Greenwich Mean"},
new string[] {"GST", "+1000", "Guam Standard"},
new string[] {"HDT", "-0900", "Hawaii Daylight"},
new string[] {"HST", "-1000", "Hawaii Standard"},
new string[] {"IDLE", "+1200", "Internation Date Line East"},
new string[] {"IDLW", "-1200", "Internation Date Line West"},
new string[] {"IST", "+0530", "Indian Standard"},
new string[] {"IT", "+0330", "Iran"},
new string[] {"JST", "+0900", "Japan Standard"},
new string[] {"JT", "+0700", "Java"},
new string[] {"MDT", "-0600", "(US) Mountain Daylight"},
new string[] {"MED", "+0200", "Middle European Daylight"},
new string[] {"MET", "+0100", "Middle European"},
new string[] {"MEST", "+0200", "Middle European Summer"},
new string[] {"MEWT", "+0100", "Middle European Winter"},
new string[] {"MST", "-0700", "(US) Mountain Standard"},
new string[] {"MT", "+0800", "Moluccas"},
new string[] {"NDT", "-0230", "Newfoundland Daylight"},
new string[] {"NFT", "-0330", "Newfoundland"},
new string[] {"NT", "-1100", "Nome"},
new string[] {"NST", "+0630", "North Sumatra"},
new string[] {"NZ", "+1100", "New Zealand "},
new string[] {"NZST", "+1200", "New Zealand Standard"},
new string[] {"NZDT", "+1300", "New Zealand Daylight"},
new string[] {"NZT", "+1200", "New Zealand"},
new string[] {"PDT", "-0700", "(US) Pacific Daylight"},
new string[] {"PST", "-0800", "(US) Pacific Standard"},
new string[] {"ROK", "+0900", "Republic of Korea"},
new string[] {"SAD", "+1000", "South Australia Daylight"},
new string[] {"SAST", "+0900", "South Australia Standard"},
new string[] {"SAT", "+0900", "South Australia Standard"},
new string[] {"SDT", "+1000", "South Australia Daylight"},
new string[] {"SST", "+0200", "Swedish Summer"},
new string[] {"SWT", "+0100", "Swedish Winter"},
new string[] {"USZ3", "+0400", "USSR Zone 3"},
new string[] {"USZ4", "+0500", "USSR Zone 4"},
new string[] {"USZ5", "+0600", "USSR Zone 5"},
new string[] {"USZ6", "+0700", "USSR Zone 6"},
new string[] {"UT", "-0000", "Universal Coordinated"},
new string[] {"UTC", "-0000", "Universal Coordinated"},
new string[] {"UZ10", "+1100", "USSR Zone 10"},
new string[] {"WAT", "-0100", "West Africa"},
new string[] {"WET", "-0000", "West European"},
new string[] {"WST", "+0800", "West Australian Standard"},
new string[] {"YDT", "-0800", "Yukon Daylight"},
new string[] {"YST", "-0900", "Yukon Standard"},
new string[] {"ZP4", "+0400", "USSR Zone 3"},
new string[] {"ZP5", "+0500", "USSR Zone 4"},
new string[] {"ZP6", "+0600", "USSR Zone 5"}
};
 
E

Ed Courtenay

Jon said:
I have put my users through so much crap with this bug it is an absolute
shame.

I have a product that reads/writes RSS 2.0 documents, among other things.
The RSS 2.0 spec mandates an en-US style of date formatting (RFC 822). I
have been using a variation of RFC 1123 (just change the time zone to an
offset, i.e. "-0800"). It seems to be writing okay, but it's failing to
parse.

I've tried changing the regional & language settings in my Windows XP
control panel so that I could test, but after getting it to work that way, a
guy from Pakistan (I think?) is still getting date parsing problems.

Here's what I've got. See ParseDateTime() below.

It looks to me like you're making a rod for your own back here; why are
you interested in the various time zones you're handling? I'm assuming
that the application you're writing is Web based, and if so just write
it from the point of view of the web server.

If you want to get an RFC 1123 (RFC 822) format date string, simply use:

DateTime dateTime = DateTime.Now;
string dateString = dateTime.ToString("R");
 
J

Jon Davis

I already said that I use a variation of RFC 1123 to get RFC 822
ToString("R") (RFC 1123), but regarding the time zone, .NET's 1123 output
always says "GMT", which is utterly useless. And rather than go with a time
zone, I decided to force a reference to the offset value rather than a time
zone. But for those RSS files (NOT files produced by my app) that my app
attempts to read that has a time zone, I have to read the time zone because
the .NET Framework DOES NOT understand time zones nor offsets.

Being neither here nor there, I'm trying to parse the date, not just produce
the date which as I said already works (using .NET's RFC 1123 formatting as
you suggest).

Jon


Ed Courtenay said:
Jon said:
I have put my users through so much crap with this bug it is an absolute
shame.

I have a product that reads/writes RSS 2.0 documents, among other things.
The RSS 2.0 spec mandates an en-US style of date formatting (RFC 822). I
have been using a variation of RFC 1123 (just change the time zone to an
offset, i.e. "-0800"). It seems to be writing okay, but it's failing to
parse.

I've tried changing the regional & language settings in my Windows XP
control panel so that I could test, but after getting it to work that way, a
guy from Pakistan (I think?) is still getting date parsing problems.

Here's what I've got. See ParseDateTime() below.

It looks to me like you're making a rod for your own back here; why are
you interested in the various time zones you're handling? I'm assuming
that the application you're writing is Web based, and if so just write
it from the point of view of the web server.

If you want to get an RFC 1123 (RFC 822) format date string, simply use:

DateTime dateTime = DateTime.Now;
string dateString = dateTime.ToString("R");

--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 
J

Jon Davis

I'm assuming
that the application you're writing is Web based, and if so just write
it from the point of view of the web server.

By the way, no it's not a web app, it's a Windows app. That's the point.
People all over the world are downloading my software. Everyone's got a
different language config on their system, so I have to force it to "en-US"
in accordance to RFC 822.

The app is http://www.powerblog.net/ if you want to further explore
assumptions as to what the scenario is.

Jon


Ed Courtenay said:
Jon said:
I have put my users through so much crap with this bug it is an absolute
shame.

I have a product that reads/writes RSS 2.0 documents, among other things.
The RSS 2.0 spec mandates an en-US style of date formatting (RFC 822). I
have been using a variation of RFC 1123 (just change the time zone to an
offset, i.e. "-0800"). It seems to be writing okay, but it's failing to
parse.

I've tried changing the regional & language settings in my Windows XP
control panel so that I could test, but after getting it to work that way, a
guy from Pakistan (I think?) is still getting date parsing problems.

Here's what I've got. See ParseDateTime() below.

It looks to me like you're making a rod for your own back here; why are
you interested in the various time zones you're handling? I'm assuming
that the application you're writing is Web based, and if so just write
it from the point of view of the web server.

If you want to get an RFC 1123 (RFC 822) format date string, simply use:

DateTime dateTime = DateTime.Now;
string dateString = dateTime.ToString("R");

--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 
E

Ed Courtenay

Jon said:
By the way, no it's not a web app, it's a Windows app. That's the point.
People all over the world are downloading my software. Everyone's got a
different language config on their system, so I have to force it to "en-US"
in accordance to RFC 822.

I don't understand where 'forcing en-US' comes into this; times
specified in RFC 822 (and in 1123 and 2822) are based on UT/GMT.

Granted, .NET's DateTime parser will not handle timezone specifiers like
PST, CDT etc., which I have to admit is a major oversight.

When writing dates, I simply would not bother trying to convert to a
local timezone - just use ToString("R"). Parsing is anpther matter
however; the following might help:

string dateFormat =
CultureInfo.InvariantCulture.DateTimeFormat.RFC1123Pattern + " zzz";
string dateString = "Tue, 27 Apr 2004 08:16:13 GMT +08:00";
Console.WriteLine("{0:R}", DateTime.ParseExact(dateString, dateFormat,
null));

So, if you parse off the timezone specifier in your input string and
replace it with the timezone offset as 'GMT [+|-]hh:mm', it should work.

Hope this helps
 
J

Jon Davis

Guys, we are completely off-topic here. I truncate (remove) the time zone /
offset before parsing the date if .NET can't parse the date automatically.
Hence I won't belabor the time zone subject any further.

The problem is that even with time zone / offset removed, while the
date/time is being parsed fine on my computer, it is not parsing on a
foreigner's computer. It is a Pakistan, I believe. Might as well be Chinese,
it doesn't matter, it *should work* if I specify "en-US", so why does it not
work?

Jon



Ed Courtenay said:
Jon said:
By the way, no it's not a web app, it's a Windows app. That's the point.
People all over the world are downloading my software. Everyone's got a
different language config on their system, so I have to force it to "en-US"
in accordance to RFC 822.

I don't understand where 'forcing en-US' comes into this; times
specified in RFC 822 (and in 1123 and 2822) are based on UT/GMT.

Granted, .NET's DateTime parser will not handle timezone specifiers like
PST, CDT etc., which I have to admit is a major oversight.

When writing dates, I simply would not bother trying to convert to a
local timezone - just use ToString("R"). Parsing is anpther matter
however; the following might help:

string dateFormat =
CultureInfo.InvariantCulture.DateTimeFormat.RFC1123Pattern + " zzz";
string dateString = "Tue, 27 Apr 2004 08:16:13 GMT +08:00";
Console.WriteLine("{0:R}", DateTime.ParseExact(dateString, dateFormat,
null));

So, if you parse off the timezone specifier in your input string and
replace it with the timezone offset as 'GMT [+|-]hh:mm', it should work.

Hope this helps

The app is http://www.powerblog.net/ if you want to further explore
assumptions as to what the scenario is.

Jon

--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 
E

Ed Courtenay

Jon said:
Guys, we are completely off-topic here. I truncate (remove) the time zone /
offset before parsing the date if .NET can't parse the date automatically.
Hence I won't belabor the time zone subject any further.

The problem is that even with time zone / offset removed, while the
date/time is being parsed fine on my computer, it is not parsing on a
foreigner's computer. It is a Pakistan, I believe. Might as well be Chinese,
it doesn't matter, it *should work* if I specify "en-US", so why does it not
work?

Jon

Sorry, I obviously misunderstood your problem; apologies for the wild
goose chase!

I don't suppose you have a stack trace of the error generated, or a copy
of the string that your parser is actually trying to work on do you?
 
J

Jon Davis

The date string in a test file for one of my guinea pig users is "Thu, 13
May 2004 15:54:25 +0200", which is what my app came up with in the
DateToRFC822String() method (see first post in thread).

Sorry, there is no stack trace. I can and may have to rebuild it with the
removal of a quiet try..catch, and have my guinea pig re-download and
re-test, but I have burdened him with like five rebuilds of my app for this
bug and I'm so embarrassed..

... If that's the only way, it's the only way *sigh*.

Jon


Ed Courtenay said:
Jon said:
Guys, we are completely off-topic here. I truncate (remove) the time zone /
offset before parsing the date if .NET can't parse the date automatically.
Hence I won't belabor the time zone subject any further.

The problem is that even with time zone / offset removed, while the
date/time is being parsed fine on my computer, it is not parsing on a
foreigner's computer. It is a Pakistan, I believe. Might as well be Chinese,
it doesn't matter, it *should work* if I specify "en-US", so why does it not
work?

Jon

Sorry, I obviously misunderstood your problem; apologies for the wild
goose chase!

I don't suppose you have a stack trace of the error generated, or a copy
of the string that your parser is actually trying to work on do you?

--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 
E

Ed Courtenay

Jon said:
The date string in a test file for one of my guinea pig users is "Thu, 13
May 2004 15:54:25 +0200", which is what my app came up with in the
DateToRFC822String() method (see first post in thread).

Sorry, there is no stack trace. I can and may have to rebuild it with the
removal of a quiet try..catch, and have my guinea pig re-download and
re-test, but I have burdened him with like five rebuilds of my app for this
bug and I'm so embarrassed..

... If that's the only way, it's the only way *sigh*.

Jon

Well, I hope this will help... ;)

Thread.CurrentThread.CurrentCulture = new CultureInfo("ur-PK");
string dateFormat =
CultureInfo.InvariantCulture.DateTimeFormat.RFC1123Pattern.Replace("'GMT'",
"zzz");
string dateString = "Thu, 13 May 2004 15:54:25 +0200";
CultureInfo parseCulture = null;
parseCulture = CultureInfo.InvariantCulture;
DateTime dateTime = DateTime.ParseExact(dateString.Replace("GMT",
"+0000"), dateFormat, parseCulture);
Console.WriteLine("{0:R}", dateTime);

If you comment out "parseCulture = CultureInfo.InvariantCulture;" you'll
get an exception, otherwise this will work as expected.
 
J

Jon Davis

is InvariantCulture based on en-US?

Ed Courtenay said:
Jon said:
The date string in a test file for one of my guinea pig users is "Thu, 13
May 2004 15:54:25 +0200", which is what my app came up with in the
DateToRFC822String() method (see first post in thread).

Sorry, there is no stack trace. I can and may have to rebuild it with the
removal of a quiet try..catch, and have my guinea pig re-download and
re-test, but I have burdened him with like five rebuilds of my app for this
bug and I'm so embarrassed..

... If that's the only way, it's the only way *sigh*.

Jon

Well, I hope this will help... ;)

Thread.CurrentThread.CurrentCulture = new CultureInfo("ur-PK");
string dateFormat =
CultureInfo.InvariantCulture.DateTimeFormat.RFC1123Pattern.Replace("'GMT'",
"zzz");
string dateString = "Thu, 13 May 2004 15:54:25 +0200";
CultureInfo parseCulture = null;
parseCulture = CultureInfo.InvariantCulture;
DateTime dateTime = DateTime.ParseExact(dateString.Replace("GMT",
"+0000"), dateFormat, parseCulture);
Console.WriteLine("{0:R}", dateTime);

If you comment out "parseCulture = CultureInfo.InvariantCulture;" you'll
get an exception, otherwise this will work as expected.


--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 
J

Jon Davis

The exception you describe would be because parseCulture is null. Try making
it en-US?

I'm going to make some subtle changes based on what you experimented ..

Jon

Ed Courtenay said:
Jon said:
The date string in a test file for one of my guinea pig users is "Thu, 13
May 2004 15:54:25 +0200", which is what my app came up with in the
DateToRFC822String() method (see first post in thread).

Sorry, there is no stack trace. I can and may have to rebuild it with the
removal of a quiet try..catch, and have my guinea pig re-download and
re-test, but I have burdened him with like five rebuilds of my app for this
bug and I'm so embarrassed..

... If that's the only way, it's the only way *sigh*.

Jon

Well, I hope this will help... ;)

Thread.CurrentThread.CurrentCulture = new CultureInfo("ur-PK");
string dateFormat =
CultureInfo.InvariantCulture.DateTimeFormat.RFC1123Pattern.Replace("'GMT'",
"zzz");
string dateString = "Thu, 13 May 2004 15:54:25 +0200";
CultureInfo parseCulture = null;
parseCulture = CultureInfo.InvariantCulture;
DateTime dateTime = DateTime.ParseExact(dateString.Replace("GMT",
"+0000"), dateFormat, parseCulture);
Console.WriteLine("{0:R}", dateTime);

If you comment out "parseCulture = CultureInfo.InvariantCulture;" you'll
get an exception, otherwise this will work as expected.


--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 
E

Ed Courtenay

Jon said:
is InvariantCulture based on en-US?

From MSDN:

"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."
 
E

Ed Courtenay

Jon said:
The exception you describe would be because parseCulture is null. Try making
it en-US?

I'm going to make some subtle changes based on what you experimented ..

Jon

Jon,

I've just looked through the code you provided, and I think I can see
where there's a potential problem.

You're parsing the error message provided by the FormatException to
determine the type of error thrown. In particular, you're assuming that
the message is going to be something like:

"The string was not recognized as a valid DateTime. There is a unknown
word starting at index 26."

or

"The string was not recognized as a valid DateTime."

and handling the last 'word' in the message; you cannot guarantee what
the format of the message will be, and bear in mind that the message
will change depending on the locale of the system. In other words, you
cannot guarantee that the exception is in English!

I'm fairly certain that this is where your problem lies.
 
E

Ed Courtenay

Ed said:
Jon,

I've just looked through the code you provided, and I think I can see
where there's a potential problem.

You're parsing the error message provided by the FormatException to
determine the type of error thrown. In particular, you're assuming that
the message is going to be something like:

"The string was not recognized as a valid DateTime. There is a unknown
word starting at index 26."

or

"The string was not recognized as a valid DateTime."

and handling the last 'word' in the message; you cannot guarantee what
the format of the message will be, and bear in mind that the message
will change depending on the locale of the system. In other words, you
cannot guarantee that the exception is in English!

I'm fairly certain that this is where your problem lies.

I've re-written your ParseDateTime function so that it doesn't rely on
the format of the FormatException message; feel free to use/abuse it!

I hope this helps...

public static DateTime ParseDateTime(string dateTime)
{
System.Globalization.CultureInfo ci = CultureInfo.InvariantCulture;

try
{
return DateTime.Parse(dateTime, ci, DateTimeStyles.AllowWhiteSpaces);
}
catch (FormatException)
{
try
{
return DateTime.ParseExact(dateTime, new string[]
{ci.DateTimeFormat.SortableDateTimePattern,
ci.DateTimeFormat.RFC1123Pattern}, ci, DateTimeStyles.AllowWhiteSpaces);
}
catch (FormatException)
{
string dateFormat =
ci.DateTimeFormat.RFC1123Pattern.Replace("'GMT'", "zzz");
foreach(string[] entry in TimeZones)
{
if (dateTime.EndsWith(entry[0]))
{
dateTime = String.Format("{0}{1}", dateTime.Substring(0,
dateTime.Length - entry[0].Length), entry[1]);
break; }
}
try
{
return DateTime.ParseExact(dateTime, dateFormat, ci,
DateTimeStyles.AllowWhiteSpaces);
}
catch (FormatException)
{
return DateTime.Now;
}
}
}
}
 
J

Jon Davis

Thanks, Ed!

The major change to be made was to pass the dateFormat param (with GMT'
changed to zzz) to ParseExact(), which you describe below, and my guinea pig
user reports that this change works (just before I got your e-mail). So
thanks very much, glad to see confirmation.

Jon



Ed Courtenay said:
Ed said:
Jon,

I've just looked through the code you provided, and I think I can see
where there's a potential problem.

You're parsing the error message provided by the FormatException to
determine the type of error thrown. In particular, you're assuming that
the message is going to be something like:

"The string was not recognized as a valid DateTime. There is a unknown
word starting at index 26."

or

"The string was not recognized as a valid DateTime."

and handling the last 'word' in the message; you cannot guarantee what
the format of the message will be, and bear in mind that the message
will change depending on the locale of the system. In other words, you
cannot guarantee that the exception is in English!

I'm fairly certain that this is where your problem lies.

I've re-written your ParseDateTime function so that it doesn't rely on
the format of the FormatException message; feel free to use/abuse it!

I hope this helps...

public static DateTime ParseDateTime(string dateTime)
{
System.Globalization.CultureInfo ci = CultureInfo.InvariantCulture;

try
{
return DateTime.Parse(dateTime, ci, DateTimeStyles.AllowWhiteSpaces);
}
catch (FormatException)
{
try
{
return DateTime.ParseExact(dateTime, new string[]
{ci.DateTimeFormat.SortableDateTimePattern,
ci.DateTimeFormat.RFC1123Pattern}, ci, DateTimeStyles.AllowWhiteSpaces);
}
catch (FormatException)
{
string dateFormat =
ci.DateTimeFormat.RFC1123Pattern.Replace("'GMT'", "zzz");
foreach(string[] entry in TimeZones)
{
if (dateTime.EndsWith(entry[0]))
{
dateTime = String.Format("{0}{1}", dateTime.Substring(0,
dateTime.Length - entry[0].Length), entry[1]);
break; }
}
try
{
return DateTime.ParseExact(dateTime, dateFormat, ci,
DateTimeStyles.AllowWhiteSpaces);
}
catch (FormatException)
{
return DateTime.Now;
}
}
}
}


--

Ed Courtenay
[MCP, MCSD]
http://www.edcourtenay.co.uk
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top