How do I take a time stamp and get a new time stamp that is a specific time tomorrow?

[Viper]

I want to set an alarm. The set time is held in a time stamp. Say I want an alarm for 5:00 AM local time tomorrow. 

This doesn't work. What will?

TIA

[Mancho00]

Add 86400 to the time (before the Seconds to Date/Time function)

Edit: Also, why are you changing the booleans to integer and adding?  Just use an OR function.

[BertMcMahan]

If you want a timestamp of 5:00 AM tomorrow, this works just fine for me at least. If you want a timestamp 24 hours from now, do what Mancho said (add 86400, which is 24 hours * 60 minutes * 60 seconds = 86,400 seconds)

[Mancho00]

---

@BertMcMahan wrote:

If you want a timestamp of 5:00 AM tomorrow, this works just fine for me at least. If you want a timestamp 24 hours from now, do what Mancho said (add 86400, which is 24 hours * 60 minutes * 60 seconds = 86,400 seconds)

---

Doing what Viper was trying to do didn't work for me, using day of month or day of year.

If you add 86400, then you can change to date/time and set the seconds, minute and hour of your choice.

[BertMcMahan]

I guess I'm not following, if I load that snippet and run the code, it returns a timestamp with the value 5:00:00.018 AM, 1/26/2019. Is that not the desired outcome? Running v2018.

(That said I'm not sure if this will work at the end of the month... I think the best solution is your option to add THEN modify the time, as you've stated, but I'm not following why OP said this didn't work, unless the last time he tried it was 12/31 last year)

Edit: Just tried it, changing the "right now" timestamp to have a "day of month" of 33 correctly sets the timestamp to Feb 2, so this does still seem to work for me. Hmm...

[aputman]

Be more specific about what doesn't work.  What you have there, adding 1 to the month should work.  There may be some edge cases that can cause problems converting the date/time record back to a timestamp (i.e. leap year).

I would replace the single iteration for loop with a while loop and wire a constant boolean to the stop terminal so that it only executes once. 

[Mancho00]

---

@BertMcMahan wrote:

I guess I'm not following, if I load that snippet and run the code, it returns a timestamp with the value 5:00:00.018 AM, 1/26/2019. Is that not the desired outcome? Running v2018.

(That said I'm not sure if this will work at the end of the month... I think the best solution is your option to add THEN modify the time, as you've stated, but I'm not following why OP said this didn't work, unless the last time he tried it was 12/31 last year)

Edit: Just tried it, changing the "right now" timestamp to have a "day of month" of 33 correctly sets the timestamp to Feb 2, so this does still seem to work for me. Hmm...

---

I'm running 2017 and it doesn't work for me. I tried changing 'day of month' to 'day of year', but that still didn't work. Maybe it's something that was fixed in 2018?

Edit: Just tried again and it worked.  Why would I be getting inconsistent results?

[aputman]

In your false case, you set the alarm time to be the current timestamp, negating what you just calculated.

[Rhidium]

Wouldn't it be more simpler to just have a timestamp set up for the time you want to have the alarm to go off.. and upon alarm, the same timestamp is just changed to the next period alarm setting?

For example have the time stamp be compared to the alarm time.. When timestamp is greater than the alarm time (compare it in seconds), it will set off the alarm (within the case statement).  Note in that within the case statement, it would increment the alarm timestamp to the new time that you want to alarm at (whether you do it in seconds, etc).

Maybe I'm missing what this person wants to do.. seems a bit vague on the details on what the true outcome they want..

If it's for calibration control of your instrumentation, you might want to do more complex stuff such as snooze the alarm, or repeat the alarm in case the person doesn't do the calibration immediately.

[rolfk]

---

@BertMcMahan wrote:

Edit: Just tried it, changing the "right now" timestamp to have a "day of month" of 33 correctly sets the timestamp to Feb 2, so this does still seem to work for me. Hmm...

---

The LabVIEW Date Time to Seconds conversion does indeed try to do some normalization such as this, but this doesn't work for all elements and is in some cases impossible since the information in the Date Time record can be ambiguous.

I therefore always try to remain from using this "feature" and doing it in different ways if possible. If you want for instance have a specific time tomorrow it is actually much safer to add 86400 seconds to the timestamp itself and then convert to Date Time record and overwrite the hours, minutes and seconds in the resulting Date Time record with the desired value, than trying to directly do calculations in the Date Time record.