Day of year bug - format date/time string and scan from string?

[Phamton]

I've noticed that the day of year returned by "Format Date/Time String.vi" starts with a value of 1 for Jan-1 while "Scan from String.vi" wants a 0 index.  Is this a bug or feature?  🙂

(I'm using Labview 2010 Service Pack 1)

[RavensFan]

It is not that it is thinking it is zero based.  It is related to the fact this is a leap year.

Try your code again, but put in a date for last year.

I'm not saying this is or isn't a bug.  Just trying to classify the root of the problem more clearly.

Interestingly, if you turn your date string into a control driving the Scan from String, and enter 2012 000, you still get Jan 2nd, 2012.  If you do 2011 000, you still get Jan 1st, 2011.

If you put in a J of 366 or larger (up to 999), it goes to the 1st day of the following year, no matter which year it is.

But this behavior definitely looks inconsistent and is possibly a bug and should be investigated.

[Yupeng_Jia]

Hi Phamton,

Thank you very much for the feedback.  Ravens is correct, this issue only relates to leap years. The solution is if you replace %j with %m %d, the correct date will be displayed. However, the feedback you brought up should be investigated.

I already filed a report of your error, so that our R&D staff can investigate the cause of it. 

Thanks again for your feedback,

[Phamton]

Thanks everyone.  For my application I needed to get a date stamp for things such as the next Monday, or two days from now, etc.  Along with a couple other calculations, it seemed easiest to do this by getting the current day of year, adding to it, and converting back to a timestamp.  Otherwise I had to deal with the varying numbers of days in each month.  

I think it would make sense and be useful if the two vi's agreed on what a given day of year meant, even in leap years. 

Paul

[RavensFan]

You may want to work with the "Seconds to Date/Time" function.  It takes a timestamp and gives you a cluster with a lot of date time information including day of the week and day of the year.  You could do a lot of things like add days and months to your time.  The corollary function of "Date/Time to Seconds" would convert it back to a timestamp.

[Phamton]

"Seconds to Date/Time" does look useful but I couldn't figure out how to make "Date/Time to Seconds" work easily as it seems like it wants all of the fields to convert back to a timestamp.  "Scan from String" nominally had the advantage that I could just give it a year and day of the year and not have to deal with day of the month.  

I wanted to be do something like tell a program to start on the next Tuesday at 8:45 AM.  The simplest way I could imagine is to subtract the current day of the week from Tuesday, modulo 7, and add this to the day of the year - then I don't have to worry about what happens at the end of the month.

[rolfk]

I think the best idea is to use seconds since for your arithmetic, because it is going to be the most consistent and robust solution. Knowing that a day has 86400 seconds is all that is needed and you won't run in possible inconsistencies with date time implementations caused by our anything but logic calender. I would hazard that the functionality of converting a timestamp into year and day of year and back is impossible to make consistent without sacrificing other possibly conflicting transformation in the Timestamp into String and Timestamp from String manipulations.

"Seconds since" being the actual base unit in all LabVIEW timestamps, it is best to do any arithmetic on it in this base unit.