Getting the date for the previous day

[johntrich1971]

---

@RavensFan wrote:

---

@Ben wrote:

---

The add/subtract a days worth of seconds work most of the time but near 2:00 AM on two days of the year it will fail.

Ben 

---

Really more like the hour before or after midnight on the days next to the time change..

Spring forward.  The day prior to the time change date, between 11pm-midnight, adding 24 hours (86,400 seconds) will skip over the day that the the time changes, and into the day after that.  You'll effectively added 2 days.  (11:30pm +24 hours will become 12:30 am 2 days later.)  Likewise for the day after the time change between midnight-1am and subtracting 24 hours leaves you on the same date.

Fall back.  Between 11pm-midnight on the date that the time changed, you subtract 24 hours, you are still in the same day.  So 11:30pm -24 hours becomes 12:30am of the same date.  Likewise the day of the time change between midnight and 1am and adding 24 hours leaves you on the same data.

I feel like I was looking at or participating in a thread in the not too distant past with this same discussion.    If I can find it again, I'll post a link to it.

I think if you used the time record functions and take the current time, arbitrarily coerce the hour to noon and convert back to a timestamp and do the addition and subtraction, you won't have an issue.

---

Ah, I see. Thanks for the explanation.

[Yamaeda]

---

@RavensFan wrote:

---

@Ben wrote:

---

The add/subtract a days worth of seconds work most of the time but near 2:00 AM on two days of the year it will fail.

Ben 

---

Really more like the hour before or after midnight on the days next to the time change..

Spring forward.  The day prior to the time change date, between 11pm-midnight, adding 24 hours (86,400 seconds) will skip over the day that the the time changes, and into the day after that.  You'll effectively added 2 days.  (11:30pm +24 hours will become 12:30 am 2 days later.)  Likewise for the day after the time change between midnight-1am and subtracting 24 hours leaves you on the same date.

Fall back.  Between 11pm-midnight on the date that the time changed, you subtract 24 hours, you are still in the same day.  So 11:30pm -24 hours becomes 12:30am of the same date.  Likewise the day of the time change between midnight and 1am and adding 24 hours leaves you on the same data.

I feel like I was looking at or participating in a thread in the not too distant past with this same discussion.    If I can find it again, I'll post a link to it.

I think if you used the time record functions and take the current time, arbitrarily coerce the hour to noon and convert back to a timestamp and do the addition and subtraction, you won't have an issue.

---

Regarding the time thread, wasn't that the one about "what date is it if i add 2 million seconds?"

In many countries the time change is around 2AM (here it's from 2->3 in spring and 3->2 in fall), which makes the error change rather small. I'd just say "we know it can happen if anyone works at 2AM on equinox".

/Y

[JÞB]

---

@Yamaeda wrote:

---

@RavensFan wrote:

---

@Ben wrote:

---

The add/subtract a days worth of seconds work most of the time but near 2:00 AM on two days of the year it will fail.

Ben 

---

Really more like the hour before or after midnight on the days next to the time change..

Spring forward.  The day prior to the time change date, between 11pm-midnight, adding 24 hours (86,400 seconds) will skip over the day that the the time changes, and into the day after that.  You'll effectively added 2 days.  (11:30pm +24 hours will become 12:30 am 2 days later.)  Likewise for the day after the time change between midnight-1am and subtracting 24 hours leaves you on the same date.

Fall back.  Between 11pm-midnight on the date that the time changed, you subtract 24 hours, you are still in the same day.  So 11:30pm -24 hours becomes 12:30am of the same date.  Likewise the day of the time change between midnight and 1am and adding 24 hours leaves you on the same data.

I feel like I was looking at or participating in a thread in the not too distant past with this same discussion.    If I can find it again, I'll post a link to it.

I think if you used the time record functions and take the current time, arbitrarily coerce the hour to noon and convert back to a timestamp and do the addition and subtraction, you won't have an issue.

---

Regarding the time thread, wasn't that the one about "what date is it if i add 2 million seconds?"

In many countries the time change is around 2AM (here it's from 2->3 in spring and 3->2 in fall), which makes the error change rather small. I'd just say "we know it can happen if anyone works at 2AM on equinox".

/Y

---

And, Of course this never happens if you report time in UTC,

Better yet, A TAI Time Format Specifier would really be beneficial by making "Time" absolutely contiguous. 

[Ben]

---

.... I'd just say "we know it can happen if anyone works at 2AM on equinox".

/Y

---

That is a luxury that I did not have when I ran into it face first.

I was developing an application where the user could configure what time of the day the log files would be closed and new ones opened. Worked great until the time changed.

And then there was the issue of the time stamps on the files...

Windows formats the time based on the current Time zone DST setting.

When the DST setting changed it made it look like my log files were off by an hour.

I tagged this post by Rolf with time related info so it may help out.

Ben

[balatim]

My final solution looks like this:

Same time previous day

'Luckily' LabView doesn't account for leap seconds, so we don't need to take that into account.

[JÞB]

---

@balatim wrote:

My final solution looks like this:

Same time previous day

'Luckily' LabView doesn't account for leap seconds, so we don't need to take that into account.

---

Not yet- its a darned good excuse to Kudos the idea for a TAI format specifier in my earlier post though 😉