LabVIEW inaccurate date computation

[Matthew_Kelton]

You've got several issues with the way you are trying to do this.

I imagine your issue is in the month case statement where you are converting the month to a number of days.  For example, this year is a leap year, so if you assumed February has 28 days, all your numbers are off a day after that.

The 42369 is only good for this year, so you will have to edit the code every year to change the value.  It is also not timezone safe, as it is 7PM on 12/31/19 for me.

You already have the cal date as a text string.  Just convert it to the date and add 30 days to it like others have outlined.  You can just use a scan from string to get it into the timestamp and process it cleanly.  You would have to adjust the format string if your dates are in the DD/MM/YYYY format.

Once you have the timestamp, you can use the other tools if you need specific info like day of month, etc for whatever you are doing elsewhere, but I imagine you can just do timestamp comparisons to see if you are out of cal.

[Matthew_Kelton · Accepted solution]

Actually, that month case statement is the source of your errors.  You are taking the month number and adding it to the day of the year, so every month you are adding an extra day.  And it is not right for a leap year, so you are off by another day.  Your year offset is also not leap year safe, so in December, you will not be adding 30 days.

Let LabVIEW do the heavy lifting and keep your math simple.

[drunkin_drum_er]

Thanks for your feedback. As requested I have attached a scaled back version of the read vi along with vi that creates the HW equipment list file.

[GerdW]

Hi drunkin,

what a Rube-Goldberg mess…

Using the data from your frontpanel:

[drunkin_drum_er]

I can top that characterization, it's more like a fustercluck. Also, I must apologize for my initial and follow-up submissions being slightly less than ideal descriptions for what this 'mess' is trying to accomplish. The feedback I have received so far has been helpful. As a result I am further scrutinizing my implementation, which leads me to make one final plea.

To clarify, the problem is not simply adding 30 days as I inaccurately described earlier. The problem is specifically tied to the re-computation of new cal due dates from the original due date string data read from the file. I expected only the extended calibration date would show the 30 day increase but the computation method is somehow time shifting all dates. Let me know what else I can provide that might help resolve this issue.

Thanks again.

[DavidBoyd]

By the way, Chris, adding thirty to the "day of month" field is a good trick.  But I can't really find where in the LabVIEW help it's stated that the Date/Time to Seconds node will properly promote a record with a "day of month" field out of range (though it nags at me that this is defined somewhere, and it clearly works...)  Do you know where it might be documented?

The standard help really makes it look like the behavior is just unspecified...

Dave

[altenbach]

---

@DavidBoyd wrote:

Do you know where it might be documented?

---

I wasn't sure and just tried and it worked. No guarantees. Most likely it just adds up the seconds for each field.

(Similarly, if you e.g. enter February 31 into a timestamp control, it will instantly normalize it for early March. :D)

[RavensFan]

---

@drunkin_drum_er wrote:

To clarify, the problem is not simply adding 30 days as I inaccurately described earlier. The problem is specifically tied to the re-computation of new cal due dates from the original due date string data read from the file. 

---

To clarify, you are looking for a way of adding days.  You haven't ever said your goal was anything else.

The problem you had is that your method of "re-computation of new cal due date" was so completely convoluted, that it just didn't work.

---

@drunkin_drum_er wrote:

I expected only the extended calibration date would show the 30 day increase but the computation method is somehow time shifting all dates. Let me know what else I can provide that might help resolve this issue.

---

If it is "time shifting all dates", then the issue is that you programmed it do to that to all dates.

If you only want the addition apply to certain dates, then you need to program the logic into your code to do just the dates you wanted.

[Bob_Schor]

---

@drunkin_drum_er wrote:

The problem is specifically tied to the re-computation of new cal due dates from the original due date string data read from the file. I expected only the extended calibration date would show the 30 day increase but the computation method is somehow time shifting all dates. Let me know what else I can provide that might help resolve this issue.

Thanks again.

---

What you "can provide that might help resolve this issue" is a small VI consisting of the code that you are using to recompute the "new cal due dates from the original due date string data".  I'm assuming you have a Date/Time string, a numeric representing "N Days Later", and an output Date/Time string.  Isolate that much code into a stand-alone VI and attach it.  Show us what (silly) thing you are doing and we can help educate you so you can (a) fix it, (b) understand where you went "wrong", and (c) learn to avoid making the same (or similar) mistakes next month.

Bob Schor

[drunkin_drum_er]

I want to thank those who provided commentary on this issue. I know where the problem lies and am in the process of taking corrective action. Unfortunately, during my debugging effort I've encountered an unrelated problem. Until today, the ATTR_HW_List.vi could generate test equipment calibration text files for the Read_Cal_Data_File.vi to process. Nothing has changed but the date. I've sent the attached file previously just in case.