Project With Same Source, Windows 7 Ok, Windows 10 Invalid Date Format

[stacker_liew 5]

I have a project built in Windows 7 using same source, run under Windows 7 perfectly, but when run under Windows 10, invalid date format happen, any one have this problem before?

utImportCSV.zip

[mausmb 13]

Hi,

 

Obviously "now" on Windows 10 is different .. Maybe  you can go via DecodeDateTime(now,myYear,myMonth,myDay, myHour, myMin, mySec, myMilli) and then construct yours datetime formats

 

 

Regards,

m

[Guest]

  On 6/24/2020 at 2:47 AM, stacker_liew said:

any one have this problem before?

Yes, hundred of times.

Looking at your attachment, i see there is StrToDateTime this you are expecting to be consistent, but it is not, Windows has per user settings for Locale means this datetime format are per user and can be different, not only different but hard to fix too, each Windows has its Region setting, there is Formats, the main problem is coming from different language has different format for many things like the separator and the "AM/PM" those enough to through you chasing goose, many problem can be solved by switching to 24h time format, but still different language has different timing calendar, and the separator can be huge pain in the back too.

 

Start there and find out how these data was exported to begin with, then how you do import them. 

Try to get sample from that not working CSV, and you will see the problem.

[Lars Fosdal 1846]

We've found that date conversion problems often stem from Windows 10 using the same separator for time and date.

 

[Guest]

  On 6/24/2020 at 6:32 AM, Lars Fosdal said:

We've found that date conversion problems often stem from Windows 10 using the same separator for time and date.

What about these "AM/PM", they are one Unicode character in different languages (Russian, Arabic...) , and often been corrupted with converting time.

[Lars Fosdal 1846]

I guess those also could raise issues, but being from Norway, it is rare that we have data with AM/PM.

Since Windows Server 2012, Windows have insisted on yy.mm.dd hh.nn.ss for the Norwegian locale, and that has caused issues with exchanging dates as string with an MSSQL database through FireDAC.  The "quick fix" that has stuck with us so far - probably because it just worked - is to change the time separator to : (colon)  leading to yy.mm.dd hh:nn:ss on the application server that communicates with the database.  Wherever that format is massaged within the Delphi conversions, that just works.

There is a lot of relatively old code in the layers between the input and the database, so one day we may take time to figure out a better solution.

[Guest]

It is not easy task and mostly ugly to fix, on other hand Windows offer wide range of functions to handle this https://docs.microsoft.com/en-us/windows/win32/api/datetimeapi/nf-datetimeapi-getdateformatex

 

And the most ugly way i did, was to give the user the choice to select few locale then get all available format for them using EnumDateFormatsEx, then go through them and show a list to the user to select what he deem right, only then parse CSV file in full, of course with remember this and don't ask again, i got that idea from Navicat, it always will ask for user input on defining the fields and their format when import CSV.

 

When you are the one who is writing the export then stick to one format and don't leave it to System or User default.

[Guest]

I seldom see problems in end-user VCL apps. Regarding TService based server-side, such things happens when a library is not flexible enough.

FastReport's "in-memo" formatting for example, sometimes, changing the global FormatSettings variable can help.

[Fr0sT.Brutal 901]

Rule #1. Always use standardized format for string representation. For dates it could be ISO 8601 or something custom but explicitly forced! F.ex. with FormatDateTime(dt, CommonFormat). The same with floats.

Rule #2. Use *ToStr functions without FormatSettings parameter only for displaying purposes. User has his locale settings so he expects data in a defined format. Don't force him to see another one (imagine if some app would force you to use 12-hour time or American MM/DD/YYYY format that makes Europeans crazy).

[Alexander Elagin 143]

  On 7/24/2020 at 11:23 AM, Fr0sT.Brutal said:

Rule #1. Always use standardized format for string representation. For dates it could be ISO 8601 or something custom but explicitly forced! F.ex. with FormatDateTime(dt, CommonFormat). The same with floats.

There are two great functions in the DateUtils module: DateToISO8601 and ISO8601ToDate. They can save a lot of pain when it is needed to store date/time in text files.

[Fr0sT.Brutal 901]

Nice to know! I guess they're more or less recent addition

 

These rules are results of personal experience. I've seen an app that required changing decimal separator from default comma to dot in system settings to work, otherwise it crashed constantly. So here comes Rule #3 (the general one)

Rule #3. Remember the world is much more complex than you may think.

 - There are different locales

 - There are different languages

 - There are different timezones

 - There are characters beyond A..Z

 - There are Right-to-left scripts

 etc

Edited July 24, 2020 by Fr0sT.Brutal