0

I created an application in which the user enter a month-year dd-MMM date as input, and this date is parsed using the DateTime.Parse() method. It is working fine on my PC.

Dim txtDate as String = combobox1.Text
Dim dtDate as DateTime =   DateTime.Parse(txtDate)

Example: 

DateTime.Parse("01-Dec")

Result:

2017-12-01 00:00:00

But when running this application on other machines, it returns 1899 year.

1899-12-01 00:00:00

After searching I found a similar question here: Time parsing Issue using DateTime.ParseExact() and it is marked as answered, but there is no solution for this situation

Does anyone knows what causes this problem?

Note: it is an old application I am working on. I know that it is recommended to replace it with a DateTime picker, but the issue is very confusing

Ali.M.
  • 51
  • 2
  • 13
  • 1
    It's extremely hard to help you without knowing what your source looks like. – Jeffrey Dec 24 '17 at 20:55
  • Did you check the system clock on those other machines? There are too many possible reasons you might get the wrong value. You'll need to provide more context, and a good [mcve] showing _exactly_ what you're doing and how it doesn't work. – Peter Duniho Dec 24 '17 at 20:55
  • the application source is very sample, just reading the `dd-MMM` from a combobox and then parsing it using `DateTime.Parse` function – Ali.M. Dec 24 '17 at 20:57
  • No matter what, your use won't enter **enough** information to create a _proper_ `DateTime` value. If you don't specify year part, it will be current year _if_ your string has valid for other parts like month, day etc.. – Soner Gönül Dec 24 '17 at 20:57
  • On the `1899` machines, what is the value of `DateTime.Now`? – mjwills Dec 24 '17 at 20:58
  • `1899` part _might_ coming from OLE by the way.. https://msdn.microsoft.com/en-us/library/system.datetime.tooadate – Soner Gönül Dec 24 '17 at 20:58
  • @mjwills it returns `2017-12-24` – Ali.M. Dec 24 '17 at 20:59
  • And why do you describe the input as _"a month-year `dd-MMM` date"_? Did you mean to write _"a day-month `dd-MMM` date"_? Or do you really think that `dd-MM` will parse as "month-year"? – Peter Duniho Dec 24 '17 at 21:03
  • Garbage In Garbage Out. The mistake here is in thinking the problem is in the behaviour. The problem is in the poorly specified input. If you know the input will always be in that format just write a simple custom parser. – James Gaunt Dec 24 '17 at 21:04
  • @PeterDuniho it is an old application I am working on. I know that I can replace it with a DateTime picker, but the issue is very confusing – Ali.M. Dec 24 '17 at 21:04
  • @Fabio I mentioned this link in my question. but it doesn't have an explanation for this issue. it is showing the framework code – Ali.M. Dec 24 '17 at 21:06
  • 1
    @Fabio: the answer posted there does _nothing_ to explain the incorrect year. The table that was posted _claims_ that you'll always get the current year when the year is not present in the parsed text. They failed to answer the question that was asked there, and likewise that answer doesn't address this one (technically, this question is a duplicate, but since there's no useful answer in that other one, this definitely shouldn't be closed as a duplicate). – Peter Duniho Dec 24 '17 at 21:07
  • 2
    @Fabio: _"It explains how framework handle cases when year not provided"_ -- it _claims_ to, but offers no actual explanation as to how "1899" got used for the year. – Peter Duniho Dec 24 '17 at 21:08
  • Well, I cannot reproduce the problem. Tested on two pc and the result is correct on both. Now the only thing that we cannot see is if there is any difference between locale on the two machines or other differences in the globalization settings. Try to print out the CultureInfo.CurrentCulture.DateTimeFormat of the two pc or pass the CultureInfo.InvariantCulture as second parameter to Parse – Steve Dec 24 '17 at 21:13
  • 1
    What is operation systems of current machine and other machines? There are difference in how Visual Basic handle string dates in Windows 10 and other Windows – Fabio Dec 24 '17 at 21:14
  • 1
    there are probably various differences between the machines such as .Net version, OS, virtual machine?, other various settings. For more consistent results use TryParseExact and InvariantCulture – Slai Dec 24 '17 at 21:16
  • @Steve after adding Cultureinfo.InvariantCulture it worked fine – Ali.M. Dec 24 '17 at 21:18
  • 1
    Well good for you, but this leaves us with an unsolved mystery. What is the locale setting causing this behavior? – Steve Dec 24 '17 at 21:22

1 Answers1

1

Date.Parse without specifying an IFormatProvider will use the current user's Culture settings to determine what formats to parse, so 01/04/2017 will be 2017-April-01 on most computers (dd/MM/yyyy) but 2017-Jan-04 on computers in the US (MM/dd/yyyy).

If you're using the same format everywhere, you should use DateTime.ParseExact and provide an explicit format.

As for your specific problem, the string 01-Dec does not specify a year component, the computer must therefore infer the date, and how that date is inferred is often down to the Culture setting too.

Dai
  • 141,631
  • 28
  • 261
  • 374
  • 6
    What you wrote is true, but I don't see how it relates to the question. `DateTime` isn't picking a format where the value `01` is being treated as the year. It's clearly picking the day and month correctly, which makes sense because a format with `MMM` in it isn't going to be ambiguous according to culture settings. If you have reason to believe that a specific culture would infer a year of 1899, please be more specific. I personally am not aware of a culture setting difference that would cause that. – Peter Duniho Dec 24 '17 at 20:58
  • 1
    after adding `CultureInfo.InvariantCulture` as a parameter it worked fine. I think that it was a `Culture` mismatch – Ali.M. Dec 24 '17 at 21:17