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

[paul_cardinale]

---

@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.

---

This is a bit ugly, but it handles DST.

[RavensFan]

I think you are neglecting an important aspect of the DST.  It all depends on what time of day NOW is.  If you are too close to midnight on the day before the change to DST, 24 hours ahead skips over the next day.  Similarly if you are just after  midnight on the day DST ends, you'll get the same day.

I turned your Current Time into a timestamp control.  I set the time to 11 pm or later on March 16, 2019.  (spring forward occurs at 2 am on March 17).  The result winds up being 7pm on March 18, completely skipping the 7pm on March 17. 

If you set it for midnight on November 3, you wind up with 7 pm on November 3rd..

Set for midnight on November 2, you get 6pm on November 3..

There may be some other corner cases besides these.

It's unlikely these things will occur.  You need to execute within a narrow hour or two window the day before or the day of the DST change.  So you many never run into this, but it is certainly possible.

It may be better after all to just add 1 day to the Day of the Month cluster if we can prove that it always updates the month and year correctly when either of them could rollover.

Otherwise it may be necessary to test the DST flag before and after the operation and put in a case structure to do the math one way in once situation, and another way in the other.

[pincpanter]

Assuming that the minimum day duration is 11 h, we may:

- add 11*3600 seconds

- if Day of Month changed, stop

- otherwise, do (add 3600 seconds) until (Day of Month changes)

(coding left to newbies for exercise )

[wiebe@CARYA]

How about adding 36 hours - current hour to the current time? (Anything between 25 and 47 will work I thing). So at 00:00 add 36. At 23:00, add 13. Both will get you 11:00, 12:00 or 13:00, but always the next day. Then set the time.

[RavensFan]

---

wiebe@CARYA wrote:

How about adding 36 hours - current hour to the current time? (Anything between 25 and 47 will work I thing). So at 00:00 add 36. At 23:00, add 13. Both will get you 11:00, 12:00 or 13:00, but always the next day. Then set the time.

---

No.  that won't work.  If it is 10 pm when you hit the button, adding 36 hours skips over tomorrow and puts it 2 days later.

I'm thinking take the current time stamp record and set the cluster to the time you want today.

Change it to time and dd 84600 seconds,

Change it to a record and and if the hour has changed, set the hour in the record again and change back to a timestamp.

[wiebe@CARYA]

---

@RavensFan wrote:

---

wiebe@CARYA wrote:

How about adding 36 hours - current hour to the current time? (Anything between 25 and 47 will work I thing). So at 00:00 add 36. At 23:00, add 13. Both will get you 11:00, 12:00 or 13:00, but always the next day. Then set the time.

---

No.  that won't work.  If it is 10 pm when you hit the button, adding 36 hours skips over tomorrow and puts it 2 days later.

I'm thinking take the current time stamp record and set the cluster to the time you want today.

Change it to time and dd 84600 seconds,

Change it to a record and and if the hour has changed, set the hour in the record again and change back to a timestamp.

---

10 PM would be the 22th hour... So adding 14 (not 26, also not 36).

[Ben]

---

@RavensFan wrote:

---

wiebe@CARYA wrote:

How about adding 36 hours - current hour to the current time? (Anything between 25 and 47 will work I thing). So at 00:00 add 36. At 23:00, add 13. Both will get you 11:00, 12:00 or 13:00, but always the next day. Then set the time.

---

No.  that won't work.  If it is 10 pm when you hit the button, adding 36 hours skips over tomorrow and puts it 2 days later.

I'm thinking take the current time stamp record and set the cluster to the time you want today.

Change it to time and dd 84600 seconds,

Change it to a record and and if the hour has changed, set the hour in the record again and change back to a timestamp.

---

I wonder why SOMEBODY would resort to repeatedly adding 1 second to the current time in a loop and testing for the day of month to change?

At first glance we could say we are wasting a lot of CPU but if we are only doing once a day, Who Cares?

That is exactly what I did in an application developed back LV 6.1 when the customer wanted to able to specify when the log files would be close and new ones opened. even with the single core machine we had back then, it was a solution that let me close out that issue.

Ben

[RavensFan]

---

wiebe@CARYA wrote:

---

@RavensFan wrote:

---

wiebe@CARYA wrote:

How about adding 36 hours - current hour to the current time? (Anything between 25 and 47 will work I thing). So at 00:00 add 36. At 23:00, add 13. Both will get you 11:00, 12:00 or 13:00, but always the next day. Then set the time.

---

No.  that won't work.  If it is 10 pm when you hit the button, adding 36 hours skips over tomorrow and puts it 2 days later.

I'm thinking take the current time stamp record and set the cluster to the time you want today.

Change it to time and dd 84600 seconds,

Change it to a record and and if the hour has changed, set the hour in the record again and change back to a timestamp.

---

10 PM would be the 22th hour... So adding 14 (not 26, also not 36).

---

But you said you were adding 36. 

Ok.  See what you are doing.  You said "36 hour - current hour".  As in Minus.  I didn't see it as a subtraction.  I thought you it was just a hyphen separating some phrases.