Will using string.Compare(timeA,TimeB) always return -1 given that:
timeA is a timestamp that happened before timeB
and
both are in this format: 12/27/2012 00:59:06 aka mm/dd/yyyy hh:mm:ss via DateTime.UtcNow
Well yes. Why would you expect that to work? If you want to sort by time, parse them both into DateTime values and compare those. You're comparing them as strings so they'll be compared lexicographically. Of course if your timestamp format was yyyy-MM-ddTHH:mm:ss or something similar, you could compare them lexicographically - but your current format just isn't designed for sorting.
You could write an IComparer<string> which did the parsing each time, but you'd be much better off just parsing the values as early as you could, and keeping them in their more native representation (DateTime) for as long as possible.
You are comparing your Timestamps as a string. Just use < and > with DateTime.Parse()
value timea = DateTime.Parse(timeA);
value timeb = DateTime.Parse(timeB);
if( timeA > timeB )
{
// your code...
}
For
string.Compare(timeA, timeB)
to work, timeA and timeB must be strings. And strings are compared alphabetically, so a string beginning with a 1, like '12/27/2012' will always be smaller that a string that begins with a 2, like '2/27/2010'.
In order to compare dates, you could use:
DateTime.Compare(timeA, timeB)
where timeA and timeB are DateTime's. If, as you say, they are both generated in your code, just avoid using a .ToString() on them.
String.Compare(string strA, string strB);
Returns:
// A 32-bit signed integer that indicates the lexical relationship between the
// two comparands.Value Condition Less than zero strA is less than strB. Zero
// strA equals strB. Greater than zero strA is greater than strB.
Related
It seems that C# does not manage to parse a time in a valid RFC 3339 format:
DateTime.ParseExact("2019-12-31T00:00:00.123456789+01:00", "yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fffffffffzzz", null)
This line throws an exception, while this line works just fine:
DateTime.ParseExact("2019-12-31T00:00:00.1234567+01:00", "yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fffffffzzz", null)
So it seems there is a limit on milliseconds, but I cannot find out any documentation on that. Is this how it is supposed to be?
The reason want to parse this date is that I have have an input date field. We use OAS (Swagger) date-time format that quite clearly says that any date in RFC 3339 Internet Date/Time format should be valid. Now from the spec here section 5.6
time-secfrac = "." 1*DIGIT
As far as I understand this means that up to 9 digits should be allowed and to be 100% compliant we have to allow these inputs, but it does not seem that C# even supports that.
Any ideas on how to fix it?
Per MSDN specification, you can use only fffffff
The fffffff custom format specifier represents the seven most
significant digits of the seconds fraction; that is, it represents the
ten millionths of a second in a date and time value.
In your first example
DateTime.ParseExact("2019-12-31T00:00:00.123456789+01:00", "yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'fffffffffzzz", null)
you are using fffffffff which is more precise for .NET custom date and time format strings
As far as I know, .NET supports seven most significant digits for milliseconds which is The "fffffff" custom format specifier are for.
The "fffffff" custom format specifier represents the seven most
significant digits of the seconds fraction; that is, it represents the
ten millionths of a second in a date and time value.
Although it's possible to display the ten millionths of a second
component of a time value, that value may not be meaningful. The
precision of date and time values depends on the resolution of the
system clock.
That means you are giving not meaningful data that are not supported for .NET Framework. I strongly suggest not doing that.
In addition to the information in the other answers, if you cannot change your input and you still want to parse it, you may use one of the following solutions:
If your input will always be in the same format (i.e., has 9 seconds-fraction digits), you could just remove the two extra ones and proceed to parse it:
string input = "2019-12-31T00:00:00.123456789+01:00";
input = input.Remove(27, 2);
// TODO: parse `input`.
If you don't know the number of the seconds-fraction digits beforehand, you may use something like this:
string input = "2019-12-31T00:00:00.123456789+01:00";
string format = "yyyy'-'MM'-'dd'T'HH':'mm':'ss'.'FFFFFFFzzz";
var regEx = new Regex(#"^(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}\.\d{1,7})\d*");
input = regEx.Replace(input, "$1");
DateTime parsedDate = DateTime.ParseExact(input, format, null);
I want to be able to parse strings of time (hours, minutes, seconds) where the hours run from 0 to 23, and where the preceding zero for one-digit hours is optional.
Examples of time strings that I want to be able to parse into valid DateTime objects:
212540
061525
94505
I am trying to use the C# method DateTime.ParseExact to manage the parsing, but I cannot for the life of it come up with a format string that can handle the "single-digit hour without preceding zero" scenario.
How should I specify the DateTime.ParseExact format string to sufficiently parse all examples above with the same line of code?
Inspired by the MSDN page on custom date and time formats, I have tried the following approaches:
DateTime.ParseExact(time_string, "Hmmss", CultureInfo.InvariantCulture);
DateTime.ParseExact(time_string, "%Hmmss", CultureInfo.InvariantCulture);
DateTime.ParseExact(time_string, "HHmmss", CultureInfo.InvariantCulture);
All these format strings work for the first two example cases above, but faced with a single-digit hour and no preceding zero, all formulations throw a FormatException.
You can insert delimiters between hours, minutes and seconds like this:
string timeString = "94505";
string formatedTimeString = Regex.Replace(str, #"\d{1,2}(?=(\d{2})+$)", "$&:");
var datetime = DateTime.ParseExact(formatedTimeString, "H:mm:ss", CultureInfo.InvariantCulture);
UPDATE:
I've found the cause of failure when parsing "94505" with format string "Hmmss":
What's happening is that H, m and s actually grabs two digits when they can, even if there won't be enough digits for the rest of the format. So the for example with the format Hmm and the digits 123, H would grab 12 and there would only be a 3 left. And mm requires two digits, so it fails.
So basically you have two options for handling the "single-digit hour without preceding zero" scenario:
Change time format: place hours to the end (for example, "ssmmH" or "mmssH") or use delimiters (for example, "H:mm:ss")
Modify the string like I've suggested earlier or like keyboardP has.
You could pad your input string if you know that you'll always have six characters.
string input = "94505";
if(input.Length < 6)
input = input.PadLeft(6, '0');
(Or use input.Length == 5 if you have other valid formats that are shorter).
What about using:
DateTime.ParseExact(time_string, "Hmmss", CultureInfo.InvariantCulture).ToString("HH:mm:ss")
I'm trying to find the appropriate format string to parse (exact) the following types of dates:
1-01-01T00:00:00+00:00 - 1 January of 0001
2011-12-14T15:53:40+00:00 - 14 December of 2011
So the year length seems to be variable (1-4 characters).
The format sting I currently use to parse exact is:
c_DateTimeFormatString = "yyyy-MM-ddTHH':'mm':'sszzz"
Obviously this only matches the second string. The first one poped up today. Now we have to match that as well.
Is there a format string to achieve this?
UPDATE #1
I added the actual dates in clear text after the input date strings.
UPDATE #2
Parse exact has an overload that allows for multiple format strings to be passed in. This seems to be the right way.
So the first try was to use:
DateTime.ParseExact("1-01-01T00:00:00+00:00 ", new[] { "yyyy-MM-ddTHH':'mm':'sszzz", "yyy-MM-ddTHH':'mm':'sszzz", "yy-MM-ddTHH':'mm':'sszzz", "y-MM-ddTHH':'mm':'sszzz" }, CultureInfo.CreateSpecificCulture("en-US"), DateTimeStyles.AssumeLocal)
But sadly this does ont give the correct result, the first date string is parsed as:
01.01.2001
rather than
01.01.0001
So the question now is what is the correct parsing string to parse year one which is represented with only one digit?
Updated based on comment:
string y = "yyyy-MM-ddTHH':'mm':'sszzz";
string testDate = "1-01-05T00:00:00+00:00".PadLeft(25, '0');
Console.WriteLine(DateTime.ParseExact(testDate, y, CultureInfo.InvariantCulture));
testDate = "2011-12-14T15:53:40+00:00".PadLeft(25, '0');
Console.WriteLine(DateTime.ParseExact(testDate, y, CultureInfo.InvariantCulture));
The output is:
1/5/0001 00:00:00
12/14/2011 15:53:40
You can use an overload of ParseExact to match multiple formats, I believe.
See MSDN.
If the input formats are not all exactly the same, you'll need either to stop using parse exact, or to call it with different format arguments depending on the format of the input data.
I don't believe you need to match a year from 1 to 4 characters but 2 or 4 characters.
For this example
1-01-05T00:00:00+00:00
you would need something like
d-MM-yyTHH':'mm':'sszzz
Try padding your string so that the year is 4 digits long. You should probably add 2, 20 or 201 and not just 0's.
Since you know that you have to support multiple formats, I suggest that you use the TryParseExact method.
If it fails to parse using one format (i.e. it returns false), then try the next format.
Can anyone explain why the following snippet returns true?
According to the docs for The "d" custom format specifier, "A single-digit day is formatted without a leading zero." So why doesn't TryParseExact fail when I give it a single-digit day with a leading zero?
DateTime x;
return DateTime.TryParseExact
(
"01/01/2001",
#"d\/MM\/yyyy",
null,
System.Globalization.DateTimeStyles.None,
out x
);
UPDATE
I think maybe I was unclear originally. What I am really trying to get at is: Why does TryParseExact accept some values that don't match exactly? from all of the documentation I have seen, 'd' matching '01' and '1' is just as much a bug as if 'MM' matched 'March' as well as '03'. The issue here isn't that the values are equivalent, its that they don't match the format.
The relevant snippets of documentation are:
From TryParseExact: The format of the string representation must match a specified format exactly.
From The 'd' Specifier: A single-digit day is formatted without a leading zero.
It seems abundantly clear to me that '01' has a leading 0, and therefore doesn't exactly match 'd'.
From the .NET 4 source in DateTimeParse.ParseByFormat():
case 'd':
// Day & Day of week
tokenLen = format.GetRepeatCount();
if (tokenLen <= 2) {
// "d" & "dd"
if (!ParseDigits(ref str, tokenLen, out tempDay)) {
if (!parseInfo.fCustomNumberParser ||
!parseInfo.parseNumberDelegate(ref str, tokenLen, out tempDay)) {
result.SetFailure(ParseFailureKind.Format, "Format_BadDateTime", null);
return (false);
}
}
if (!CheckNewValue(ref result.Day, tempDay, ch, ref result)) {
return (false);
}
}
else
{...}
The parser lumps "d" and "dd" together.
It appears that behavior is by design, and I think it works that way to be consistent with other string formatting options.
Take the following example:
//Convert DateTime to string
string dateFormat = "d/MM/yyyy";
string date1 = new DateTime(2008, 10, 5).ToString(dateFormat);
string date2 = new DateTime(2008, 10, 12).ToString(dateFormat);
//Convert back to DateTime
DateTime x1, x2;
DateTime.TryParseExact(date1, dateFormat, null, System.Globalization.DateTimeStyles.None, out x1);
DateTime.TryParseExact(date2, dateFormat, null, System.Globalization.DateTimeStyles.None, out x2);
Console.WriteLine(x1);
Console.WriteLine(x2);
In the first part, ToString() outputs a two digit day for October 12th, because it wouldn't make much sense to just write out a single digit day (and which digit would it pick, the 1 or the 2?). So since the "d" represents one OR two digit days when converting to a string, it would have to work the same way when converting back to DateTime. If it didn't, the conversion back to DateTime in TryParseExact in my example would fail, and that would definitely not be an expected behavior.
I would say that if you really need to match a d/MM/yyyy format exactly, you could probably use a regex to validate the string and then pass it through Parse, TryParse or TryParseExact (depending on how good your regex is, since it would have to handle leap years, 30/31 days, etc if you wanted to use Parse).
I'd say it doesn't fail because TryParseExact is smart enough to know that '01' == '1'.
TryParseExact is just trying to be flexible in this case I guess. But the "d" vs "dd" should and would work as advertised when you are converting date to string using a format specifier.
Because a single 'd' means that your DateTime value will be converted to as short value as possible, i.e. without leading zero if there's no necessity for it. I suppose it shouldn't fail when you're converting from string to DateTime because the main purpose of TryParseExact's format string is to help to convert to DateTime, i.e. it serves like a hint, it's not intended to validate string format.
You can use RegEx if you still need hardcore string format validation.
For the following code, I would expect result to equal 2, because the MSDN states that 'd' "Represents the day of the month as a number from 1 through 31. A single-digit day is formatted without a leading zero.".
DateTime myDate = new DateTime( 2009, 6, 4 );
string result = myDate.ToString( "d" );
However, result is actually equal to '6/4/2009' - which is the short-date format (which is also 'd'). I could use 'dd', but that adds a leading zero, which I don't want.
To indicate that this is a custom format specifier (in contrast to a standard format specifier), it must be two characters long. This can be accomplished by adding a space (which will show up in the output), or by including a percent sign before the single letter, like this:
string result = myDate.ToString("%d");
See documentation
Rather than using string formatting strings, how about using the Day property
DateTime myDate = new DateTime(2009,6,4)
int result = myDate.Day;
Or if you really needed the result in string format
string result = myDate.Day.ToString();
If you are looking to get a specific date part out of a date object rather than a formatted representation of the date, I prefer to use the properties (Day, Month, Year, DayOfWeek, etc.) It makes reading the code a bit easier (particularly if someone else is reading/maintaining it that doesn't have the various formatting codes memorized)