Dates In Revolution

[Gregory Lypny]

Hi Sarah,

On Thu, Feb 2, 2006, at 10:58 AM, Sarah responded:

>> 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.
>
> Ooops - it was meant to check item 4, not the last item. Sorry  
> about that.
> However I have not seen this problem in recent versions of Rev.
>
> However, I agree with you that there are problems with the current
> dateTime stuff in Rev. One that causes me lots of problems is that
> "the seconds" refers to the number of seconds since midnight on
> 1/1/1970 GMT. So the actual numeric value translates into completely
> different times depending on your local time zone. I have lobbied for
> an addition to the syntax called "the local seconds" which refers to
> an absolute time regardless of time zones & daylight savings.

	The seconds that have elapsed since January 1st, 1970 is an  
absolute, that is, independent of time zone and regional adjustments  
for Daylight Savings Time, so I don't think there can be a problem  
with the seconds function.  I imagine that Revolution's definition of  
the seconds mentions GMT because it is only absolute when calculated  
relative to GMT.  That's a good thing.  But changing the seconds into  
a date and time requires the convert command, and because the convert  
command makes adjustments without information about it's input, it  
will be wrong unless the input conforms to the assumptions underlying  
the command.

	I'm not sure whether the Revolution team knows how serious the  
problem with the convert command is because it has gone unfixed for a  
few years now.  Anyone creating software that requires precise date  
and time stamps cannot use convert with confidence.  That includes  
web storefronts, CGIs that use tokens, multi-person games, research  
using historical data (I'm up you-know-what creek on this one), and  
anything involving a queue that would regulate the order of execution  
of requests.  The answer is simple, however, as I pointed out in my  
original post: get rid of any and all adjustments that the convert  
command makes.  Convert is useful because of the many formats it  
supports, and the most important for date and time calculations is  
the dateItems.  It is up to scripters to know or anticipate the  
origin of the date and time data that their programs receive, and so  
it best left to the scripters to make the adjustments.  There is no  
other way.


>
> However if "convert" made no changes to the time when it did it's
> conversion, this would have the same effect. Perhaps we need the
> ability to add an extra parameter to the convert command. Something
> like:
>     convert absolute tDate to dateItems
>
> If you want more info about dates & times in Rev, I contributed a
> scripting conference stack on the topic, which you can get at
> <http://support.runrev.com/scriptingconferences/>

	Thanks, I'll have a look at it.

		Greg