Dates In Revolution

[Gregory Lypny]

Thanks for your responses, Ken and Sarah.

I think you're date-routine function is going to come in handy and  
dandy today, Ken.  Thank you.

Sarah, in response to your question, I'm using version 2.6.1, build  
152 for OS X.  I used your handler below, but it returns the last  
item of the dateItems, which is the numeric day of the week.  Perhaps  
I've misunderstood its purpose because my problem is with the way the  
Convert command attempts to adjust hours.  As my example shows and  
Ken points out, Convert adds one hour during Daylight Savings Time  
every time it is used on the same time-stamp.  It should not.  And  
the bigger problem, thinking back on my research (gulp), is that it  
does it with other date and time formats, not just the dateItems!    
I'm going to be busy.

If I'm not mistaken, Convert is intended to convert date and time  
formats for appearance, while the dateItems is intended to provide an  
easy way to do date and time calculations, presumably when it is  
included in home made functions.  The Convert command should not make  
any adjustment to dates or times because it cannot know whether it is  
being fed actual values or being asked to make an adjustment for time  
zones relative to GMT or for Daylight Savings Time.  If an  
observation I'm working with is June 2, 1963 3:00 PM, then that's  
what it is.  I may be working on a machine localized to Montreal or  
Toronto, but that observation could refer to an event that took place  
in Frankfurt.  The Convert command simply does not have the  
information it needs to make any adjustment and so should not.  I  
think the only way to do date and time calculations in Revolution is  
to create functions specifically for that purpose.  Finding what the  
local date and time was five months, two days, and six hours ago, for  
example, requires an adjustment for Daylight Savings Time; but the  
number of hours that have passed since noon on August 28th, 2005 does  
not.  Programs like Mathematica make use of a function called  
AbsoluteTime[] and AbsoluteTime[time zone], which is essentially the  
Seconds in Revolution, but leaves all adjustments for Daylight  
Savings Time up to the programmer because it is so idiosyncratic.   
Mathematica's other date and time functions assume that all inputs  
are local or from the same time zone.  Taking a quick look at Excel  
and FileMaker, I could not find any mention of built-in adjustments.

My recommendation is that Convert be made to simply convert formats.

	Regards,

		Gregory