Inconsistent behaviour with date/zone
[1/3] from: pwawood::mango::net::my at: 16-Jan-2005 13:23
The function to-date appears to perform selective validation on the supplied
time zone giving a script error :
>> a: to date! "10-11-04 03:00 +00:31"
** Script Error: Invalid argument: 10-11-04 03:00 +00:31
** Near: a: to date! "10-11-04 03:00 +00:31"
Through experimentation I have determined that to-date will on accept 00 or
30 minutes.
Yet if you directly "set" the zone of a date, Rebol happily rounds the zone
down to either 00 or 30 minutes:
>> b: to-date "10-11-04 03:00"
== 10-Nov-2004/3:00
>> b/zone: 00:31
== 0:31
>> b/zone
== 0:30
I also found that to-date is quite happy to accept strange timezones
provided they are a multiple of 30 minutes:
>> e: to-date "10-11-04 03:00 +26:00"
== 10-Nov-2004/3:00+26:00
Regards
Peter
[2/3] from: SunandaDH::aol::com at: 16-Jan-2005 4:25
Hi Peter,
> The function to-date appears to perform selective validation on the supplied
> time zone giving a script error :
You are finding out lots of useful stuff there. Nest step may be RAMBO.
Real-world timezone offsets should allow 00 30 and 15....bits of Canada and
all of India use a 30 minute offset. And Nepal is shifted another 15 minutes
from India.
So maybe the offset should not be restricted at all,
Best wishes,
Sunanda.
[3/3] from: greggirwin:mindspring at: 16-Jan-2005 10:27
Peter and Sunanda,
Definitely some info worthy of writing down in a document somewhere.
Sac> Real-world timezone offsets should allow 00 30 and 15....bits of Canada and
Sac> all of India use a 30 minute offset. And Nepal is shifted another 15 minutes
Sac> from India.
If that's the case for Nepal (and perhaps it's the only 0:15
increment), let RT know. The design is obviously based on only 0:30
intervals being valid.
Sac> So maybe the offset should not be restricted at all,
Do the 'net RFCs enforce any constraints for validity? Not sure how
you would use them without constraints--unless you had a virtual world
with funky timezones.
-- Gregg