DateTime time = DateTime.ParseExact("946AM", "hmmtt", CultureInfo.InvariantCulture);
Is there something wrong here? I have tried several different variations of the format, but this is the one I'd expect to work.
Thanks
The documentation for ParseExact contains the following note in the remarks section:
If format is a custom format pattern that does not include date or time separators (such as "yyyyMMdd HHmm"), use the invariant culture for the provider parameter and the widest form of each custom format specifier. For example, if you want to specify hours in the format pattern, specify the wider form, "HH", instead of the narrower form, "H".
You are indeed lacking separators. Worse, your data uses at least one variable-width field -- it is likely that you will need to write some of the parsing logic yourself or at least sanitize the data before passing it to ParseExact
Related
I have a file-path that's been created from DateTime stamp:
"C:\\Logs\\Tests\\2015\\Mar\\24\\13_32_09\"
Now I am trying to convert my file-path back to DateTime object.
With Regex I can easily remove "C:\\Logs\\Tests\", but now I am assume I need to provide implementation of IFormtProvider to convert 2015\\Mar\\24\\13_32_09\ into a DateTime object, but I haven't come along any similar example of how that's usually done.
Any example, may not be particular solution to my answer, would be helpful.
Thanks
You can use DateTime.ParseExact like:
DateTime dt = DateTime.ParseExact("2015\\Mar\\24\\13_32_09\\",
#"yyyy\\MMM\\dd\\HH_mm_ss\\",
CultureInfo.InvariantCulture);
No, you don't need to create an IFormatProvider at all. The invariant culture is fine for this (assuming the month name is always in English). You can just use DateTime.ParseExact, passing in the appropriate custom format string (quoting the literal characters, either with apostrophes around them or backslashes before them):
var dateTime = DateTime.ParseExact(
text,
#"yyyy'\'MMM'\'dd'\'HH'_'mm'_'ss'\'",
CultureInfo.InvariantCulture);
Note that this assumes the path really does use backslashes... it won't work on Unix as-is. (You might want to canonicalize the directory separators first.)
I have some code that is logging a timestamp in format from a thick client app
DateTime.UtcNow.ToString("MM/dd/yy HH:mm:ss")
Now, on a client running in China (not sure exactly which locale) this is producing a date in the log with the format
11-20-13 02:14:03
I notice it's using - instead of / to delimit the parts, even though I explicitly wanted /
I tried to set the current culture to Chinese simplified zh-CN but I wasn't able to reproduce how the remote client was able to produce that string
Does current culture locale affect the output of this format string? Or does / have some other meaning I'm not aware of?
Yes, the / character is a placeholder for whatever the current culture uses to separate parts of the date. From MSDN:
The "/" custom format specifier represents the date separator, which is used to differentiate years, months, and days. The appropriate localized date separator is retrieved from the DateTimeFormatInfo.DateSeparator property of the current or specified culture.
As with other format specifiers, you can escape the / with a \:
DateTime.UtcNow.ToString(#"MM\/dd\/yy HH\:mm\:ss")
Or specify an explicit culture when formatting the string:
DateTime.UtcNow.ToString("MM/dd/yy HH:mm:ss", CultureInfo.InvariantCulture)
Yes, that's how it works. / is being replaced with the local date separator. The same applies to : as a time separator. You can find more on MSDN: Custom Date and Time Format Strings.
To change that, escape them with \:
DateTime.UtcNow.ToString(#"MM\/dd\/yy HH\:mm\:ss")
I have a string date like so:
var sDate = '3/3/2012'
It eventually goes into a DateTime.ParseExact(sDate, "MM/dd/yyyy")
and it fails because of the missing leading zeros.
What's the best way to add the leading zeros?
I know TryParse would have worked but can't refactor at the moment.
What's the best way to add the leading zeros?
Why would you do that? Just use ParseExact with the format it's actually got, which is M/d/yyyy.
The whole point of the format string is to let you declare the format of your data - not to make you change the format of your data.
Note that you can specify multiple patterns with this overload, so you could always pass in both M/d/yyyy and MM/dd/yyyy. I believe M/d/yyyy will work with zero-padded ones anyway though...
Why does:
DateTime.Now.ToString("M")
not return the month number? Instead it returns the full month name with the day on it.
Apparently, this is because "M" is also a standard code for the MonthDayPattern. I don't want this...I want to get the month number using "M". Is there a way to turn this off?
According to MSDN, you can use either "%M", "M " or " M" (note: the last two will also include the space in the result) to force M being parsed as the number of month format.
What's happening here is a conflict between standard DateTime format strings and custom format specifiers. The value "M" is ambiguous in that it is both a standard and custom format specifier. The DateTime implementation will choose a standard formatter over a customer formatter in the case of a conflict, hence it is winning here.
The easiest way to remove the ambiguity is to prefix the M with the % char. This char is way of saying the following should be interpreted as a custom formatter
DateTime.Now.ToString("%M");
Why not use
DateTime.Now.Month?
You can also use System.DateTime.Now.Month.ToString(); to accomplish the same thing
You can put an empty string literal in the format to make it a composite format:
DateTime.Now.ToString("''M")
It's worth mentioning that the % prefix is required for any single-character format string when using the DateTime.ToString(string) method, even if that string does not represent one of the built-in format string patterns; I came across this issue when attempting to retrieve the current hour. For example, the code snippet:
DateTime.Now.ToString("h")
will throw a FormatException. Changing the above to:
DateTime.Now.ToString("%h")
gives the current date's hour.
I can only assume the method is looking at the format string's length and deciding whether it represents a built-in or custom format string.
I have a function that parses a string containing a date(and/or time) e.g. "2009-12-10". I get the order of year-month-day from the Short Date pattern. When going through the string I use Char.IsSeparator(ch) to figure out when the numbers end.
Now however in the case of Korean it seems the Char.IsSeparator(ch) returns false on separator characters. Is there any way to know whether the chars in between the numbers are separator regardless of region setting?
(I also parse strings that are more free containing things like "*20 May 200*9" so doing Char.IsAlphaNum() on the separator will not work either as I don't know the content basically)
Example inputs: "20.10.2009" "2009-05-20" "20 May 2009" "20.05.2009 10:00 AM" "1/1/2009" (in Singapore its D/M/Y in US it is M/D/Y") "Tisdag, 1 Januari 1962" (all strings localized)
Output would be an equivalent of a DateTime instance filled as much as possible (although we use our own types).
Korean seems to have a couple of characters in front of the time and as separator it looks like the symbols are different depending on position in the string.
If you pick up the format using the current short format, you could perhaps also be able to pick up the separator through DateTimeFormatInfo.CurrentInfo.DateSeparator.
Is there any reason why you need to parse the string manually?
If you used the built-in date/time parsing methods - Parse, ParseExact, TryParse or TryParseExact - then you could pass in the required culture-specific format info and let the framework worry about separators etc.