Date\Time rec overflow inconsistency strikes back!

[tst]

In this thread, I noted an inconsistency in the way the date\time cluster handled overflow in its different elements.

This seems to have been fixed in a later LV version.

Mostly...

Overflowing the month element still generates an empty timestamp, as can be seen in the attached VI (8.5).

[Nick R]

This was reported to R&D (# 4CSANOYT) for further investigation. Thanks for the feeback!

[Roy_F]

---

@Nick R wrote:
This was reported to R&D (# 4CSANOYT) for further investigation. Thanks for the feeback!

---

Correction in CAR number:

This was reported to R&D (# 4CSANHYT) for further investigation.

Roy

[DBerry]

Just wondering what the status of this CAR is?  I am using LV 2012 and still seem to have the issue with month rollover error.  I would have thought this would have been fixed by now.

Dan

[Kurt-P]

Hey DBerry,

There is a new corrective action report number associated with this problem. It is 41014. You can use this in README file to see if the bug is in the current or future releases. This thread is also from 2007. If this issue persists, it is better to post a new thread so we can log the issue with our research and developement team. 

Thank you, 

[Roy_F]

We don't actually need a new thread.

The referenced CAR has been closed by R&D with the determination that it is not a bug. The documentation states the limits of the month field are 1-12. We understand this is inconsistent with our handling of rollover for seconds, even though that field is defined as limited to 0-59. While an argument could be made that our handling of the rollover is a bug, we obviously wouldn't change that since allowing it does no harm and fixing it could break code that is currently working.

Roy

[Jeff-P]

Edit - Already answered by Roy