Something very unusual ...
-
Honestly, this post should go into some kind of support forum but it is one intriguing error that I do not even know whether to call it a bug or not ... It is fairly likely that this thing is already solved somehow by locale of which I am yet to get the precise clue. OK! all of the contents of this post (rant) revolves around DateTime, something that we, fortunately agree on values but just cannot have uniformity on how we'd like to store, read on screen and pass around. I am writing one .net application in C# that parses dates and times coming in from a ASCII bytestream. This problem only occurs when date is sent as ASCII string. From the very beginning, I had decided that I will only keep one dedicated function to parse strings into dates. At first, this function started with "dd/MM/yyyy HH:mm:ss". In a different record, I discovered "yyyyMMdd". In yet another place, I discovered only date, no month "dd-MMM-yyyy". Given that I am in India, this is the defacto date format used, so no problems. All of these were very efficiently handled by DateTime.TryParse no problems, but then I started getting dates being sent as "MM/dd/yyyy HH:mm:ss" which is like a giant monkey spanner at TryParse regardless of the locale setting. If locale is set to American, 07/01 gets read as July 1. If I set locale to British, 07/01 gets read 7 January. At least some of the byte stream format will be read incorrectly if I use same locale setting!!! At least for first 12 days of all month, this would read date incorrectly!!! Cannot use TryParse. Cannot tell people sending me bytestream to fix up the mess. I want data, so its my headache on how to read it... Fortunately, I do tag attributes on field on what format date is it going to be in. All in all, between 50 different bytestreams, I get string dates in formats listed below. List is sorted by frequency of occurrence. Rest of them come either as # of seconds from some epoch or pair of integers. "MM/dd/yyyy HH:mm:ss", "dd/MM/yyyy HH:mm:ss", "yyyy-MM-dd HH:mm:ss.fff", "yyyy-MM-dd HH:mm:ss.ff", "yyyy-MM-dd HH:mm:ss.f", "ddMMMyyyy", "yyyyMMdd", "dd-MMM-yyyy" fff are miliseconds and honestly only one should be needed, but I do get 1, 2 or 3 digits after the decimal!!! In my function, I've plonked the all format strings into a static String array and then loop over it like this ... try catch inside the loop allows loop to go to next format if current one fails.
for (int i = 0; i < DateFormatStrings.Length; i++)
{
try -
Honestly, this post should go into some kind of support forum but it is one intriguing error that I do not even know whether to call it a bug or not ... It is fairly likely that this thing is already solved somehow by locale of which I am yet to get the precise clue. OK! all of the contents of this post (rant) revolves around DateTime, something that we, fortunately agree on values but just cannot have uniformity on how we'd like to store, read on screen and pass around. I am writing one .net application in C# that parses dates and times coming in from a ASCII bytestream. This problem only occurs when date is sent as ASCII string. From the very beginning, I had decided that I will only keep one dedicated function to parse strings into dates. At first, this function started with "dd/MM/yyyy HH:mm:ss". In a different record, I discovered "yyyyMMdd". In yet another place, I discovered only date, no month "dd-MMM-yyyy". Given that I am in India, this is the defacto date format used, so no problems. All of these were very efficiently handled by DateTime.TryParse no problems, but then I started getting dates being sent as "MM/dd/yyyy HH:mm:ss" which is like a giant monkey spanner at TryParse regardless of the locale setting. If locale is set to American, 07/01 gets read as July 1. If I set locale to British, 07/01 gets read 7 January. At least some of the byte stream format will be read incorrectly if I use same locale setting!!! At least for first 12 days of all month, this would read date incorrectly!!! Cannot use TryParse. Cannot tell people sending me bytestream to fix up the mess. I want data, so its my headache on how to read it... Fortunately, I do tag attributes on field on what format date is it going to be in. All in all, between 50 different bytestreams, I get string dates in formats listed below. List is sorted by frequency of occurrence. Rest of them come either as # of seconds from some epoch or pair of integers. "MM/dd/yyyy HH:mm:ss", "dd/MM/yyyy HH:mm:ss", "yyyy-MM-dd HH:mm:ss.fff", "yyyy-MM-dd HH:mm:ss.ff", "yyyy-MM-dd HH:mm:ss.f", "ddMMMyyyy", "yyyyMMdd", "dd-MMM-yyyy" fff are miliseconds and honestly only one should be needed, but I do get 1, 2 or 3 digits after the decimal!!! In my function, I've plonked the all format strings into a static String array and then loop over it like this ... try catch inside the loop allows loop to go to next format if current one fails.
for (int i = 0; i < DateFormatStrings.Length; i++)
{
try -
Honestly, this post should go into some kind of support forum but it is one intriguing error that I do not even know whether to call it a bug or not ... It is fairly likely that this thing is already solved somehow by locale of which I am yet to get the precise clue. OK! all of the contents of this post (rant) revolves around DateTime, something that we, fortunately agree on values but just cannot have uniformity on how we'd like to store, read on screen and pass around. I am writing one .net application in C# that parses dates and times coming in from a ASCII bytestream. This problem only occurs when date is sent as ASCII string. From the very beginning, I had decided that I will only keep one dedicated function to parse strings into dates. At first, this function started with "dd/MM/yyyy HH:mm:ss". In a different record, I discovered "yyyyMMdd". In yet another place, I discovered only date, no month "dd-MMM-yyyy". Given that I am in India, this is the defacto date format used, so no problems. All of these were very efficiently handled by DateTime.TryParse no problems, but then I started getting dates being sent as "MM/dd/yyyy HH:mm:ss" which is like a giant monkey spanner at TryParse regardless of the locale setting. If locale is set to American, 07/01 gets read as July 1. If I set locale to British, 07/01 gets read 7 January. At least some of the byte stream format will be read incorrectly if I use same locale setting!!! At least for first 12 days of all month, this would read date incorrectly!!! Cannot use TryParse. Cannot tell people sending me bytestream to fix up the mess. I want data, so its my headache on how to read it... Fortunately, I do tag attributes on field on what format date is it going to be in. All in all, between 50 different bytestreams, I get string dates in formats listed below. List is sorted by frequency of occurrence. Rest of them come either as # of seconds from some epoch or pair of integers. "MM/dd/yyyy HH:mm:ss", "dd/MM/yyyy HH:mm:ss", "yyyy-MM-dd HH:mm:ss.fff", "yyyy-MM-dd HH:mm:ss.ff", "yyyy-MM-dd HH:mm:ss.f", "ddMMMyyyy", "yyyyMMdd", "dd-MMM-yyyy" fff are miliseconds and honestly only one should be needed, but I do get 1, 2 or 3 digits after the decimal!!! In my function, I've plonked the all format strings into a static String array and then loop over it like this ... try catch inside the loop allows loop to go to next format if current one fails.
for (int i = 0; i < DateFormatStrings.Length; i++)
{
tryMaybe the whitespace is not a space (ASCII 32), but a tab (ASCII 15)? Anyway, try Q&A.
Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
-
Maybe the whitespace is not a space (ASCII 32), but a tab (ASCII 15)? Anyway, try Q&A.
Pablo. "Accident: An inevitable occurrence due to the action of immutable natural laws." (Ambrose Bierce, circa 1899).
Pablo Aliskevicius wrote:
Maybe the whitespace is not a space (ASCII 32), but a tab (ASCII 15)?
Pablo. No, it always has been spaces. But I do have code with few String.Replace(...) to weed out all unwanted chars. Not happening nowadays but earlier, separating char between dd and mm used be any one of /, \ or - In any case, at moderator's suggestion, I've reposted this query at C# forum. Thank you for your help