The seconds problem - summarized?

[SimPLsol at aol.com]

     What a response!
     As I was signing off for the evening last night Sarah was posting 
another suggestion. Apparently the pace kept up today because the emailbox was full 
when I got back to the office. I'll try to summarize the hilights.
     Dar, your gmt is different from my gmt. I believe that, by definition, 
gmt does NOT accommodate time zones and daylight saving time. If the GMT is 
10:29 in Greenwich, then the GMT time at that instant is 10:29 in Wapello, Iowa; 
Mt. Maunganui, New Zealand; and Katmandu, Nepal. The fact that GMT is constant 
allow sailors to compute longitude by comparing GMT to local (sun) time. The 
ability to access GMT seconds would solve the problem I presented - and others 
listed since. I'll come back to this below.
     Jacque, I agree that dateItems should solve the original one day 
increment which started this thread. I say "should" because I've been experimenting 
with dateItems in place of seconds and there appear to be some "anomalies" 
there as well - too early to tell, I have not dug into them as deeply as the 
seconds. But, even allowing for this, dateItems is not a complete solution:
     1. Many date programming situations are handled easier with seconds. 
Calculating days between dates is much easier with seconds - especially if the 
month, year, or century changes between the dates.
     2. The Rev documentation says a programmer can use either seconds or 
dateItems to work with universal time. I believe the documentation describes the 
correct situation - not the actual one.
     3. Unsuspecting programmers can get into real trouble using seconds the 
way they work now.
     4. HyperCard had no trouble (in my experience) handling date math based 
on seconds. Of course the Rev team is under no obligation to support legacy HC 
syntax or features - but they have done a wonderful job of it to date, this 
was one of the reasons I chose Revolution when it came time to "move on".
     Sarah, I am so glad you wrote! You seem to understand the importance of 
this issue. It is obvious you have actually run into some of the problems I 
described - and more. Also, thanks for the list of the bug numbers.
     Sarah, Mark, and Rob, I need to know more about Julian dates. Wasn't 
there a problem with the way the Julian calendar handled leap years which caused 
Pope Gregory to revise it substantially?
     Rob and Brian, I believe Rob's reply was identical to what mine would 
have been, just more prompt and more eloquent.
     Mark, thanks for the insight on the problem from a European perspective. 
I did not realized there were these additional issues.
     Rob quoting Dar, "How can routines to store, sort, and otherwise 
manipulate dates be "calendar independent"? I thought, when I began the thread, that 
"simpleSeconds" would solve the problem (with simpleSeconds the date starts 
with 0 and progresses uniformly at the rate of 86400 seconds per day). That 
would solve my problem. But, based on what I'm hearing, there would be a better, 
more universal solution if we had access to "gmtSeconds" (the ability to 
convert both ways any local time, any time of the year, in any time zone, on any 
platform to the current number of seconds since the eon at Greenwich).
     This would also solve my problem, make programming easier for Sarah's 
and Rob's projects, probably address Mark's situation with the unpredictable 
dates and even clarify time in more unique situations like the one where you 
finish a proposal in Auckland, fly to LA,   and discover your proposal is dated 
tomorrow.
     So, two questions:
     1. Is gmtSeconds the answer?
     2. If "yes", then what is a realistic cost for writing such a function?
     3. Of course there will be a three, depending on the answer to #2.
Paul Looney