| Type | Bug | Status | tested | Date | 24-Jun-2009 10:05 |
|---|---|---|---|---|---|
| Version | alpha 62 | Category | n/a | Submitted by | meijeru |
| Platform | All | Severity | minor | Priority | normal |
| Summary | time-zone in DATE! values is restricted to multiples of 30 minutes |
|---|---|
| Description |
from the comment to #959 it appears that restrictions on the time-zone value are undesirable however, there is one currently in force |
| Example code |
>> d: now == 24-Jun-2009/11:06:03+1:00 >> d/zone: 0:15 == 0:15 >> d == 24-Jun-2009/11:06:03+0:00 >> make date! [24 6 2009 11:06 +0:15] ** Script error: cannot MAKE/TO date! from: [24 6 2009 11:06 0:15] |
| Assigned to | n/a | Fixed in | alpha 67 | Last Update | 6-Jul-2009 21:34 |
|---|
| Comments | |
|---|---|
|
(0001047)
BrianH 24-Jun-2009 14:08 |
Testing current variants:
; Sri Lanka >> 24-Jun-2009/1:00+5:30 == 24-Jun-2009/1:00+5:30 ; Kathmandu, Nepal >> 24-Jun-2009/1:00+5:45 ** Syntax error: invalid "date" -- "24-Jun-2009/1:00+5:45" ; Caiguna, Western Australia >> 24-Jun-2009/1:00+8:45 ** Syntax error: invalid "date" -- "24-Jun-2009/1:00+8:45" ; Chatham Islands, New Zealand (dst) >> 24-Jun-2009/1:00+12:45 ** Syntax error: invalid "date" -- "24-Jun-2009/1:00+12:45" ; Tonga (nice place) >> 24-Jun-2009/1:00+13:00 == 24-Jun-2009/1:00+13:00 ; Line Islands, Kiribati >> 24-Jun-2009/1:00+14:00 == 24-Jun-2009/1:00+14:00 ; nowhere >> 24-Jun-2009/1:00-12:00 == 24-Jun-2009/1:00-12:00 >> 24-Jun-2009/1:00-13:00 == 24-Jun-2009/1:00-13:00 So, time zones greater than +12 and less than -12 work, but not the :45 ones (and certainly not the :40 one that Nepal used to have before it got an official time zone, which we can ignore). A resolution of :15 should do. |
|
(0001052)
meijeru 24-Jun-2009 15:19 |
Or abandon all restrictions?!? The arithmetic stays the same, and REBOL cannot track reality, as was remarked earlier. |
|
(0001053)
BrianH 24-Jun-2009 17:19 |
It depends on how many bits R3 has allocated in memory for the zone in the date! and time! structures. |
|
(0001057)
meijeru 25-Jun-2009 09:15 |
I checked this, and multiples of 30 minutes up to 31:30 are positive, then +32:00 is accepted but comes out as -32:00, up to +63:30 which comes out as -00:30, and +64:00 = 00:00. Any positive and negative multiple of 00:30 is accepted in any case, but they are taken module 64:00 and then treated like above. This would indicate 7 bits (0..127) and in the byte there is room for one more, allowing us to go to 00:15 indeed. I assume that the date is packed in 24 bits (year 0..16383 needs 14 bits, month 1..12 needs 4 bits and date 1..31 needs "just" 5 bits, again having one to spare...). |
|
(0001239)
BrianH 6-Jul-2009 21:34 |
In alpha 67, now accepts +15:45 to -15:45 in 15-minute increments. |
| Date | User | Field | Action | Change |
|---|---|---|---|---|
| 6-Jul-2009 21:34 | BrianH | Comment : 0001239 | Added | - |
| 6-Jul-2009 21:32 | BrianH | Status | Modified | built => tested |
| 6-Jul-2009 18:54 | carl | Fixedin | Modified | => alpha 67 |
| 6-Jul-2009 18:54 | carl | Status | Modified | reviewed => built |
| 25-Jun-2009 09:15 | meijeru | Comment : 0001057 | Added | - |
| 24-Jun-2009 17:19 | BrianH | Comment : 0001053 | Added | - |
| 24-Jun-2009 15:19 | meijeru | Comment : 0001052 | Added | - |
| 24-Jun-2009 14:09 | BrianH | Description | Modified | - |
| 24-Jun-2009 14:09 | BrianH | Code | Modified | - |
| 24-Jun-2009 14:09 | BrianH | Status | Modified | submitted => reviewed |
| 24-Jun-2009 14:08 | BrianH | Comment : 0001047 | Modified | - |
| 24-Jun-2009 14:08 | BrianH | Comment : 0001047 | Added | - |
| 24-Jun-2009 10:05 | meijeru | Ticket | Added | - |