Since your string contains an offset, you're much better off parsing it to a DateTimeOffset
with the zzz
specifier than to a DateTime
with the K
specifier.
The problem with K
is that if any numeric offset is present, the kind will be treated as DateTimeKind.Local
, and the date and time part of the value will be adjusted from the provided offset to the local time zone. You likely don't want that behavior.
string dateRange = "Mon Oct 07 2019 00:00:00 GMT-0400 (Eastern Daylight Time)Sat Nov 23 2019 00:00:00 GMT-0500 (Eastern Standard Time)";
string[] parts = dateRange.Split('(',')');
string format = "ddd MMM dd yyyy HH:mm:ss 'GMT'zzz";
DateTimeOffset start = DateTimeOffset.ParseExact(parts[0].Trim(), format, CultureInfo.InvariantCulture);
DateTimeOffset end = DateTimeOffset.ParseExact(parts[2].Trim(), format, CultureInfo.InvariantCulture);
Console.WriteLine(start.ToString("o")); // 2019-10-07T00:00:00.0000000-04:00
Console.WriteLine(end.ToString("o")); // 2019-11-23T00:00:00.0000000-05:00
Working example here
Also, if I were to guess I'd say this format were created by concatenating the output of two JavaScript Date
objects in a browser (either via toString
explicitly, or just implicitly). Is that correct? If so, you should probably not send this format to your back-end, but rather call .toISOString()
to get a UTC-based ISO 8601 formatted string, or use a function such as this one to get an ISO 8601 formatted string that is based on the local time of the user. Either output are much better choices to parse in your .Net code than the human-readable strings you are currently using.
One really good reason to do this is that "Mon" and "Oct" are valid abbreviations in English. You may encounter difficulties with users of other languages.