new date conversion bug?
I am working on a scheduling program that includes the ability to schedule an event every other week over a specific time period. To determine whether the event should occur during any given week during the time period I do some simple date math to figure out whether a multiple of 14 days have passed since the first occurrence of the event. Let's say I've scheduled an event for every other week on Friday, beginning January 11, 2008 and ending April 11, 2008. For any given week on my calendar I can calculate whether the event should show up using this algorithm (pseudocode): get the date of the first occurrence of the event and convert it to seconds get the date of that the event should fall on if this week falls in the every-other-week pattern, convert it to seconds subtract date 2 from date 1 divide the difference by (60*60*24*14) --the number of seconds in 14 days if the difference divides evenly (modulo division = 0) then the event should occur in the week in question This works fine for a few weeks, but then inexplicably fails. For example, Jan. 11, Jan. 25, Feb. 8, Feb. 22, and March 7 all show the event properly. But anything after that fails; i.e., March 21, April 4. Here is a simulation I did of my code in the multiline message box: convert 1/11/08 to seconds; put it into tD1; put tD1 convert 3/7/08 to seconds; put it into tD2; put cr tD2 after msg put tD2 - tD1 into diff; put cr diff after msg put cr (diff div (24*60*60*14)) after msg put cr (diff mod (24*60*60*14)) after msg Results: 1200034800 --D1 seconds 1204873200 --D2 seconds 4838400 --difference 0 --diff mod 14 days worth of seconds --OK! BUT: convert 1/11/08 to seconds; put it into tD1; put tD1 convert 3/21/08 to seconds; put it into tD2; put cr tD2 after msg put tD2 - tD1 into diff; put cr diff after msg put cr (diff mod (24*60*60*14)) after msg Results: 1200034800 --D1 seconds 1206079200 --D2 seconds 6044400 --difference 1206000 --diff mod 14 days worth of seconds --BZT! Wrong! Now if you do some quick math it turns out that the second example is 3600 seconds--1 hour-- short of a full 14 days! This reminds me of a date conversion bug we were dealing with a year ago or so. So am I looking at some weird convert bug? Or is the bug in my brain? (I'm prepared to accept either possibility.) ;-) BTW, this is Rev v. 2.8.1 on Intel Mac OS X 10.4.11. The same thing happens in 2.9.0-dp-3. No Windows box to check on. Regards, Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: new date conversion bug?
Devin, You might want to check into Sarah's* Date and time library: http://www.troz.net/Rev/libraries.php *with contributions from noted Revarians Eric Chatonet and Mark Weider I am working on a scheduling program that includes the ability to schedule an event every other week over a specific time period. To determine whether the event should occur during any given week Regards, Devin Devin Asay -- stephen barncard s a n f r a n c i s c o - - - - - - - - - - - - ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: new date conversion bug?
Devin Asay wrote: I am working on a scheduling program that includes the ability to schedule an event every other week over a specific time period. To determine whether the event should occur during any given week during the time period I do some simple date math to figure out whether a multiple of 14 days have passed since the first occurrence of the event. Let's say I've scheduled an event for every other week on Friday, beginning January 11, 2008 and ending April 11, 2008. For any given week on my calendar I can calculate whether the event should show up using this algorithm (pseudocode): get the date of the first occurrence of the event and convert it to seconds get the date of that the event should fall on if this week falls in the every-other-week pattern, convert it to seconds subtract date 2 from date 1 divide the difference by (60*60*24*14) --the number of seconds in 14 days if the difference divides evenly (modulo division = 0) then the event should occur in the week in question This works fine for a few weeks, but then inexplicably fails. For example, Jan. 11, Jan. 25, Feb. 8, Feb. 22, and March 7 all show the event properly. But anything after that fails; i.e., March 21, April 4. I'm not sure why it would fail; that one hour difference is suspiciously like a time zone error or a daylight savings time error (which would still be a bug, if that's what's happening.) But changing the calculation to use dateitems seems to work okay (and avoids all those inscrutable big numbers): put 1/11/08 into tDate put 4/15/08 into tStopDate convert tStopDate to seconds repeat convert tDate to dateitems add 14 to item 3 of tDate convert tDate to seconds if tDate tStopDate then exit repeat convert tDate to short date -- if you need that put cr tDate after fld 1 -- or fill your calendar field here end repeat -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: new date conversion bug?
At 1:52 PM -0700 1/31/08, Devin Asay wrote: This works fine for a few weeks, but then inexplicably fails. For example, Jan. 11, Jan. 25, Feb. 8, Feb. 22, and March 7 all show the event properly. But anything after that fails; i.e., March 21, April 4. It appears to be something odd about March 9th, and not to do with the number of days apart they are. Try this: convert 3/9/2008 to seconds; put it into tD1; put tD1 convert 3/10/2008 to seconds; put it into tD2; put cr tD2 after msg put cr (tD2 - tD1) mod (24*60*60) after msg 1205038800 1205121600 82800 Now, you would think that March 10th was exactly a day after March 9th, but it appears not to be. In HyperCard it is: on dd convert 3/9/2008 to seconds put it into tD1 convert 3/10/2008 to seconds put it into tD2 put (tD2 - tD1) mod (24*60*60) end dd 0 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: new date conversion bug?
On Feb 1, 2008 6:52 AM, Devin Asay [EMAIL PROTECTED] wrote: I am working on a scheduling program that includes the ability to schedule an event every other week over a specific time period. To determine whether the event should occur during any given week during the time period I do some simple date math to figure out whether a multiple of 14 days have passed since the first occurrence of the event. Let's say I've scheduled an event for every other week on Friday, beginning January 11, 2008 and ending April 11, 2008. For any given week on my calendar I can calculate whether the event should show up using this algorithm (pseudocode): get the date of the first occurrence of the event and convert it to seconds get the date of that the event should fall on if this week falls in the every-other-week pattern, convert it to seconds subtract date 2 from date 1 divide the difference by (60*60*24*14) --the number of seconds in 14 days if the difference divides evenly (modulo division = 0) then the event should occur in the week in question This works fine for a few weeks, but then inexplicably fails. For example, Jan. 11, Jan. 25, Feb. 8, Feb. 22, and March 7 all show the event properly. But anything after that fails; i.e., March 21, April 4. I would assume that daylight savings changes for you between March 7 March 21, so that explains the hours difference. It has long been a source of annoyance to me that the seconds is altered to allow for time zones and daylight savings, so that the same number will convert to a different time date on different systems and depending on the time of year it refers to. Effectively, this means that you cannot really use the seconds for such date time operations. How about this sort of thing (again in pseudo code): get the date of the first event convert it to dateItems add 14 to item 3 convert back to date (which will work even if you have something that looks weird in date items e.g. 2008,3,42,) Cheers, Sarah ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: new date conversion bug?
At 7:33 AM +1000 2/1/08, Sarah Reichelt wrote: I would assume that daylight savings changes for you between March 7 March 21, so that explains the hours difference. Good call, as you can see: http://aa.usno.navy.mil/faq/docs/daylight_time.php it matches the March 9th date I figured out. ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: new date conversion bug?
On Jan 31, 2008, at 2:33 PM, Sarah Reichelt wrote: On Feb 1, 2008 6:52 AM, Devin Asay [EMAIL PROTECTED] wrote: I am working on a scheduling program that includes the ability to schedule an event every other week over a specific time period. To determine whether the event should occur during any given week during the time period I do some simple date math to figure out whether a multiple of 14 days have passed since the first occurrence of the event. Let's say I've scheduled an event for every other week on Friday, beginning January 11, 2008 and ending April 11, 2008. For any given week on my calendar I can calculate whether the event should show up using this algorithm (pseudocode): get the date of the first occurrence of the event and convert it to seconds get the date of that the event should fall on if this week falls in the every-other-week pattern, convert it to seconds subtract date 2 from date 1 divide the difference by (60*60*24*14) --the number of seconds in 14 days if the difference divides evenly (modulo division = 0) then the event should occur in the week in question This works fine for a few weeks, but then inexplicably fails. For example, Jan. 11, Jan. 25, Feb. 8, Feb. 22, and March 7 all show the event properly. But anything after that fails; i.e., March 21, April 4. I would assume that daylight savings changes for you between March 7 March 21, so that explains the hours difference. RRRGH! Of course, I'd completely forgotten that the daylight savings time change was moved up to March! At first I was wondering if it had something to do with the leap year, but that wouldn't have explained why March 7th was okay. Thanks Stephen, Sarah, Jacque and Colin for your responses and suggestions. I can fix it now. I love this list! Devin Devin Asay Humanities Technology and Research Support Center Brigham Young University ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
