The seconds problem - redefined

Brian Yennie briany at qldlearning.com
Thu Apr 15 05:08:59 EDT 2004


Paul,

Unfortunately I think you'll find that the base assumption is simply 
false- there are not the same number of seconds between days. In 
reality, not just in Revolution. If you actually starting counting on 
Jan 1, 1970 and then right after you set your clocks ahead you just 
divided your count by the number of seconds in a day... you'd get the 
wrong idea! You'd think it was still an hour earlier, but it's not, 
because you just set the clocks ahead... and then some areas of the 
world don't recognize daylight savings time, etc, etc- it gets very 
messy.

I would use higher level stuff... do you ever really need to know the 
seconds passed since 1970 for a calendar app? If not, then no sense in 
messing with them. Store a date and a time, and manipulate them using 
dateItems. You can add minutes, hours, days, months, whatever you want 
there.

- Brian

>      Since I raised this topic I've gotten a LOT of good advice.
> Unfortunately most of it does not address the problem. Apparently I 
> have not defined it
> well, please bear with me and I'll try again:
>      Start with a list of events: employee birthdays, anniversaries, 
> start
> dates, order due out dates, raw material due in dates, conferences, 
> training
> sessions, etc. The list is dynamic; new employees are hired, new 
> materials are
> purchased, materials scheduled previously arrive, etc.
>      Which events in that list will be happening, by day, for the next 
> x
> days?
>      For simplicity assume there are only three items in the event 
> list; the
> first event occurs on April 3rd 2004, the second on April 4th, and the 
> third
> on April 5th.
>      Revolution converts each date in the event list to seconds as 
> follows:
>           April 3, 2004 - converts to 1080986400 seconds (OK)
>           April 4, 2004 - converts to 1081069200 seconds (will be a 
> problem)
>           April 5, 2004 - converts to 1081155600 seconds (also a 
> problem,
> because of the 4th)
>      Next create a day by day calendar showing events from the event 
> list
> above for each calendar day. Start on April 2nd (1080900000 seconds) 
> and review
> four days, adding 86400 to get the comparison seconds for the next day 
> to be
> reviewed:
>           April 2, 2004 = 1080900000 seconds,
>                empty (correct, no events in the event list above match 
> this
> date)
>           April 3, 2004 = 1080986400 seconds (1080900000 + 86400)
>                one event (correct, matches the April 3 seconds from 
> the event
> list above)
>           April 4, 2004 = 1081072800 seconds (1080986400 + 86400)
>                no match, (wrong, April 4 in the list above is short 
> 3600
> seconds, because April 3                only had 23 hours according to 
> Revolution)
>           April 5, 2004 = 1081159200 seconds (1081072800 + 86400)
>                no match (wrong, April 5 in the list above is also 
> short 3600
> seconds,
>                indeed all dates until the 25 hour day in the autumn 
> will not
> match)
>
>      If our review had started on the 4th (after the 23 hour day), all 
> dates
> would have matched correctly (until the 25 hour day in autumn).
>
>      Hope that helps. Now back to the original question. Is there a 
> way to
> convert dates to seconds where every day has 86400 seconds?
>      Note: For this purpose, I don't care whether the seconds start at 
> GMT or
> GMT - 10. I'm not concerned about time zones, daylight savings time, 
> etc. It
> doesn't matter to me if the eon starts in 1900, 1904, or 1970. I just 
> want a
> way to convert dates to consistent seconds - without having to 
> introduce extra
> calculations for short and long day variations.
>      1. Does such a conversion exist in Revolution now?
>      2. If not, shouldn't it?
> Paul Looney
> PS Note that the seconds in the samples above will not correspond to
> conversions you get - unless you are computing in the same time zone 
> that I am - I
> believe this is another problem. One that also calls for consistent 
> seconds based
> on GMT.
> PPS More fuel on the fire: finding days between dates will not produce 
> whole
> numbers if you convert the dates to seconds and divide by 86400 - when 
> the
> date range spans a 23 or 25 hour day.
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>



More information about the use-livecode mailing list