Date Formatting Issue When Running as Executable

[yusuf.eker]

Hello,

I am working on an application in LabVIEW and have encountered the following issue:

• Working Scenario: When running the VI through the Project Explorer, the date and time data are formatted correctly and displayed as expected (see the "Working Example" screenshot).
• Problematic Scenario: However, after compiling the application into an executable (EXE) and running it in debug mode, the date formatting appears incorrect (see the "Problematic Example" screenshot). For example, the year value is displayed as "1600," which is clearly incorrect.

I have tried the following steps to resolve the issue, but without success:

1. Format String Check: Verified the format string %<%H:%M:%S%5u %d.%m.%Y>T in both VI and executable modes. The same format string is being used in both cases.
2. Regional Settings: Checked the operating system's regional settings, but found no discrepancies.
3. Debug Mode: Ran the compiled EXE in debug mode to confirm that the code behaves the same way, but the output differs.

Questions:

1. What could be the possible reasons for such date formatting issues when transitioning to the executable mode?
2. How can I ensure that the application displays the date correctly in the compiled version?
3. Has anyone faced a similar issue or has suggestions for a solution?

I have attached screenshots for reference:

• Working Example: The correct output when running from the Project Explorer.
• Problematic Example: The incorrect output when running in debug mode as an executable.

Thank you in advance for your help and suggestions.

Best regards,
Yusuf Eker

[GerdW · Accepted solution]

Hi Yusuf,

in your "not working" screenshot that fraction part isn't parsed correctly: in my experience the ScanFromString has problems with obeying regional setting and using a dot before the seconds fraction.

Sometimes I ended up in parsing the usual Time (%H:%M:%S), the fractions (%.;%f) and the date (%d.%m.%Y) separately…

[yusuf.eker]

Hi GerdW,

Thank you for your response. I manually parse every text using "Search/Split String" and "Search and Replace String." I have resolved my issue, but this problem was not a good experience for me when considering LabVIEW for my future projects. This is because I had to uncheck the "Use localized decimal point*" option in the Front Panel settings, and it works when I open the app in Project Explorer. However, if my settings don't carry over to the executable app, why should I pay for this LabVIEW application? This is a big question mark for me.

Best regards,
Yusuf Eker

[GerdW]

Hi Yusuf,

---

@yusuf.eker wrote:

However, if my settings don't carry over to the executable app, why should I pay for this LabVIEW application? This is a big question mark for me.

---

Settings in the LabVIEW.ini don't automatically "carry over" to your Executable.ini!

You are responsible to define any needed keys in your own Executable.ini. (There is a setting in the AppBuilder to use your own Executable.ini instead of a default one!)

---

@yusuf.eker wrote:

This is because I had to uncheck the "Use localized decimal point*" option in the Front Panel settings, and it works when I open the app in Project Explorer.

---

So you use a regional setting that uses a different decimal separator char than English point (like my German settings).

Then unsetting the "use localized decimal point" is a workaround in the LabVIEW IDE - and applies ONLY to the LabVIEW IDE.

The better way to handle such issues is to either explicitely define the decimal point in your code (like using the %.; or %,; format codes) or to convert all "numeric" strings from comma to point (still a dangerous workaround). (On the other hand the "%<>T" format code doesn't care about the %.;/%,; format specifiers, it always expects a point before the second fractions AFAIK)

This is part of some ISO8601 handling code:

I read the time without fractions and parse them separately when they exist.

Using ISO8601 simplifies some cases with timestamps as you can expect a certain data order in the input…

The general rule for ALL programming languages is: YOU need to sanitize ALL input data, especially user input!

---

@yusuf.eker wrote:

I manually parse every text using "Search/Split String" and "Search and Replace String." I have resolved my issue,

---

I would use 3 chained ScanFromString functions, with "%<%H:%M:%S>T" (time without fraction), "%.;%f" (fraction) and "%<%d.%m.%Y>T" (date) format codes…

When parsing time with second fractions and using the %u format code I believe it doesn't care how many digits you want to parse (but please test on your own to be sure).