November 3, 2013

[babbie]

I have run into a bizarre problem that I've solved but don't understand.

In a scheduling program, I search the stack of appointments, looking for anything with today's date, then I add (24*3600) to the date (in seconds) and look again.

Everything works fine until I reach November 3, 2013, and it just keeps repeating that date. This has happened consistently no matter what the starting date was.

I wrote a little test script that illustrates the problem.

on mouseUp
put empty into msg
put "1383541200" into ddy
repeat with nc = 1 to 3
put ddy & " " after msg
convert ddy to long date
put ddy & return after msg
convert ddy to seconds
add (24*3600) to ddy
end repeat
end mouseUp

This produces three identical rows in msg:

1383541200 Sunday, November 3, 2013
1383541200 Sunday, November 3, 2013
1383541200 Sunday, November 3, 2013

In my scheduling script, however, adding the line
if ddy = 1383541200 then add (24*3600) to ddy
solves the problem. It shows any legitimate appointments for November 3, 2013, and moves forward.

Can anyone explain this to me?

Tnx

~earl

[Klaus]

Hi earl,

hmm, your script works fine here in germany:
1383541200 Monday, November 4, 2013
1383606000 Tuesday, November 5, 2013
1383692400 Wednesday, November 6, 2013

Maybe some daylight saving related stuff?
Sorry, no ida what's going on there...


Best

Klaus

P.S.
Since this is anything but OFF-TOPIC, I will move this thread to another forum...

[babbie]

Very interesting.

I tried the test program again and it keeps producing MY result, not YOURS.

November 3, 2013, is indeed the end of daylight savings here and is probably the key to the problem.

I hadn't written the program by March 10th, so I don't know if it would have happened then.

However, I just entered dummy appointments for March 9, 10, and 11, and they all worked fine.

Hmmmmmmmmm.

~earl

[dave_probertGA6e24]

I just tried your snippet (cut 'n' pasted into the messagebox) here, and got the same results as Klaus.

I'm located in Thailand - no daylight savings as far as I know. Most people here don't really care much about what time of day it is anyway!

Try this version to see if it makes any difference:

Code: Select all

put empty into msg
put "1383541200" into ddy
repeat with nc = 1 to 3
  put ddy & " " after msg
  put ddy into tempddy
  convert tempddy to long date
  put tempddy & return after msg
  add (24*3600) to ddy
end repeat

This bypasses the double convert (slightly more efficient as if that matters!) and it produces these results (note the difference in the numbers):

Code: Select all

1383541200 Monday, November 4, 2013
1383627600 Tuesday, November 5, 2013
1383714000 Wednesday, November 6, 2013

*edit: The second convert of the ddy in your code is producing a different seconds value for that date - probably midnight as seconds. Adding an exact day's worth of seconds to that will normally go into the next date, but if the date has DST/BST then the extra hours' worth of seconds is not being accounted for. The solution would be to continue with the 2 uses of convert, but Add 25 (or 26) hours to the output. This would push the value well into any DST date, but the second convert for the next date would reset the difference back to the start of the day correctly. Try it and see!

Cheers,
Dave

[babbie]

Thanks, Dave.

Your modification makes all the difference, and I got your result.

So if I understand correctly, converting ddy to seconds, then to long date,
and back to seconds causes it to go crazy on 11/3/13. Leaving it as seconds
avoids that.

Thanks to both you and Klaus. You are good coaches.

~earl

[dave_probertGA6e24]

Hi Earl,

You are actually going about things the right way for your original version. My version would not work with DST either.

It's not so much as it goes crazy, but just can't handle exact numbers of seconds on a leap day - where there is an Extra hour. The other end, where there is one less hour, is ok.

Think of it this way:

AA = 123
AA converted to 'date' = "10/10/2013" (Yes, I know it's a load of rubbish as a seconds value - bear with me )
AA converted from string (as above) to seconds = 100 (the last seconds were lost because the convert uses the start of the day)
add 123 to AA = 223

When you add a 24 hours' worth of seconds to the start of the day you get the start of the next day - except when the day has More than 24 hours worth of seconds!

Obviously the numbers above would be very much bigger but that is the essence of the problem.

Using the technique of adding 26 hours worth will not affect things because the second convert loses the extra seconds and so keeps everything in the proper place

It's kinda thinking out of the box and is something that most people would cry out against - using 26 hours as a day, but it works

So, after all that, stick with your version, but change the (24*3600) to (26*3600) and you should be quite happy.

I hope that helps you (and others) get your heads around the wonders of leap year effects!

Cheers,
Dave

[babbie]

That's brilliant, Dave. It's an easier change and it works.

Thanks so much.

[jacque]

If you don't care about the actual time of day, another common trick is to set the time to 2 AM before doing any conversions. That bypasses any hourly differences due to daylight savings time.