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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
