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

[pincpanter]

Also, take care of DST if relevant. Due to DST, there may be one day lasting (86400-3600) s and another lasting (86400+3600) s, so adding 86400 to the current date may not set the cluster day of month member to the next calendar day. Very rare but not impossible. Sometimes, working with dates can be really awkward.

[Viper]

---

@RavensFan wrote:

---

@Viper wrote: Choosing 5:00 am was arbitrary yet before shift begins. If they started my program at 9:30 am adding 86,400 would set the alarm for 9:30 the next day. If they then continued the next day at 7:00 am (shift start) then the alert would be very late and errors could occur because they missed this wanted daily operation.

No. You didn't follow along completely with what Rolf was saying in message 10. You add 86400 seconds to get a timestamp set for tomorrow.  The same time as now, but exactly 1 day in the future.  But then you use the cluster to set the hour, minutes and seconds to be the time you want.  Effectively it does the same thing you are doing by adding 1 day to the day of the month.  But doing math on the cluster elements doesn't always correlate to a real date.   So if it is Jan. 31 and you add 1 to the day of the month, you have Jan. 32 which doesn't exist.  If all works well LabVIEW will turn that into Feb. 1.  But there are some cluster elements that don't reliably recalculate the date when you roll over.  I know because of played with this before and sometimes it works and sometimes it doesn't.

But if you add 86,400 to the timestamp, it correctly calculates the timestamp for tomorrow, then you can change the cluster elements to give the correct time for tomorrow.  That is the more robust solution.

---

Like this?

[RavensFan]

Yes.  Exactly.

[Ben]

---

@pincpanter wrote:

Also, take care of DST if relevant. Due to DST, there may be one day lasting (86400-3600) s and another lasting (86400+3600) s, so adding 86400 to the current date may not set the cluster day of month member to the next calendar day. Very rare but not impossible. Sometimes, working with dates can be really awkward.

---

Ditto That!

One day of the year has 23 hours and another has 25 hours.

Since the day of the year when that happens is determined by law which is controlled by politicians... nobody can predict ahead of time ( as in write the code today that will work going into the future without failure) which ay of the year we have to add 23 or 25 hours. The last time the bozos changed that dates of DST, Windows had to be updated to adapt to the law changes.

So if the application has to be able to adapt, you may be forced to start adding seconds to the current time stamp and format the times stamp to test if the day changed.

And God help you if that "TIME" is in the 2:00 hour where one day skips 2:00 AM and the other days has two 2:00AMs.

My name sake had a lot of good ideas but day light savings time was not Ben Franklin at his best.

Ben 

[aputman]

---

@Ben wrote: 

My name sake had a lot of good ideas but day light savings time was not Ben Franklin at his best.

---

According to the source of all knowledge on the Internet, Wikipedia says that Ben didn't actually come up with DST.  Some British guy named George Hudson did.  So we can blame it on the Brits.  

[aputman]

I know there was a documentary once about a map on the back of the Declaration of Independence written in invisible ink.  And in that documentary, they did claim that Ben came up with DST but apparently they were wrong.  

[pauldavey]

I just wanted to add that instead of calculating the number of seconds in a day, you can use the units "d". If you add a constant "1" with units set to "d" to a timestamp, it will do just what you want it to, and possibly be easier to read.

Here is an example:

https://forums.ni.com/t5/LabVIEW/Subtracting-time/m-p/3795770#M1071099

[JB]

Here is the snippet of paul_cardinale's VI.

[wiebe@CARYA]

---

@Viper wrote:

---

@RavensFan wrote:

---

@Viper wrote: Choosing 5:00 am was arbitrary yet before shift begins. If they started my program at 9:30 am adding 86,400 would set the alarm for 9:30 the next day. If they then continued the next day at 7:00 am (shift start) then the alert would be very late and errors could occur because they missed this wanted daily operation.

No. You didn't follow along completely with what Rolf was saying in message 10. You add 86400 seconds to get a timestamp set for tomorrow.  The same time as now, but exactly 1 day in the future.  But then you use the cluster to set the hour, minutes and seconds to be the time you want.  Effectively it does the same thing you are doing by adding 1 day to the day of the month.  But doing math on the cluster elements doesn't always correlate to a real date.   So if it is Jan. 31 and you add 1 to the day of the month, you have Jan. 32 which doesn't exist.  If all works well LabVIEW will turn that into Feb. 1.  But there are some cluster elements that don't reliably recalculate the date when you roll over.  I know because of played with this before and sometimes it works and sometimes it doesn't.

But if you add 86,400 to the timestamp, it correctly calculates the timestamp for tomorrow, then you can change the cluster elements to give the correct time for tomorrow.  That is the more robust solution.

---

Like this?

---

Of course a feedback node would avoid any loop...

[Ben]

another trivial point about time...

When you look at the modify date time of a file using Windows the time is formatted using the current DST setting.

So file modified at 2:00AM will look like they were modified at 1:00 or 3:00 if you check them after the DST has changed.

See what happens when people "...seek to change times and laws..."

Ben