Sheeri K. Cabral wrote:
On 12/31/08, *Roland Bouman* <[email protected]
<mailto:[email protected]>> wrote:
Hi!
On Wed, Dec 31, 2008 at 4:36 PM, Tim Soderstrom
<[email protected] <mailto:[email protected]>> wrote:
> Works for me! Though the possibility of a more complex DURATION
type sounds
> tantalizing :)
INTERVAL is the usual keyword.
Actually, I'm not sure limiting TIME is what we want, nor is DURATION
exactly the same as interval. Well, it can be thought as such, but
let's say I have an event whose duration is 1 day, 3 hours, 4 minutes, 5
seconds and 10 microseconds? The duration is 27:04:05.10, but there's
no way to represent that. Specifying it as an INTERVAL would be:
INTERVAL 1 DAY + INTERVAL 3 HOUR + INTERVAL 4 MINUTE + INTERVAL 5 SECOND
+ INTERVAL 10 MICROSECOND
I don't think this is a good way to store durations longer than
23:59:59.99, nor do I think it's easy to compare durations of longer
> than 1 day.
It's tedious, but it's not that tedious. The "standard" specification
goes something like:
INTERVAL DAY TO SECOND(6) '1 03:04:05.000010'
Is there really the need to have TIME be 3 bytes? IIRC the reason it's
4 and the reason 838 is such an odd amount of hours is that it is
limited by the # of seconds in a 4-byte INT.
It's one thing to limit the DATE functions to valid dates, but there
*is* a valid TIME of 27:00:00 -- if something takes 27 hours.
Provided that you are talking about a duration. The standard
interpretation of TIME is a point in time within a day, possibly with a
time zone. But you are of course allowed to extend that interpretation...
Thanks,
Roy
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
