Asp.net problem with dates and database update

Question

User-1935883977 posted

I've picked up a site on my pc (Windows 10) which I post in a calendar diary (Javascript calendar). In the debug with Visual Studio 2017 it works fine. It is published in another pc server (windows server 2019) and in storage it does not seem that this day is a Public holiday when the day falls 1-9 of the month (eg first day of May) . Are regional server settings? I changed everything with my pc, but the same ones.

At MySQL Workbench, the date is in the '2019-05-01' format, and in the code when I create the date to compare it to the base if it is a day, I get a string by checking if the day is 1-9 and I get '0' in the first place to make it 'yyyy-mm-dd' so I can compare it to the base. Maybe IIS settings ? I dont know , any help!!

Answer 1

User753101303 posted

Hi,

Unclear. Public holidays are stored in a table. I'm not nusing MySQL but your db should store values using their "native" values ie not  as string but as date columns. Similarly the app should be written to handle properly the string to "native" value conversion.

For now it seems you are maybe comparing strings which are not matching or that because of some error May 1 is actually Januaray 5 ???

Answer 2

User-1935883977 posted

Hi,

Τhank you very much, but i insert January 5 as holiday ,and i have the same effect . It is the problem with the '0' in front of the day from 1-9 . When i put holiday after 10th day of a month

the result is correct .

Answer 3

User753101303 posted

Hi,

So it seems you really stored those dates as strings.

A short term fix could be to use https://docs.microsoft.com/en-us/previous-versions/bz9tc508(v=vs.140) to force the culture your app is using. For now my guess is that you are not using the same culture on both sides and that you end up with a different string representation for the same date (I remember to have seen once that some cultures are using a leading 0 while others are not using a leading 0).

A longer term better fix could be to use really use dates. The general idea is to always work with "native" values (ie you'll convert your date to a string only when showing the value to a user).