Обсуждение: any additional date_time functions?
I am working with the date_trunc() function with great success especially in the group by clause for aggregates. However, it is limited to returning "WHOLE" time units. i.e. years, months, days, hours, minutes, seconds. Are there any functions similar to date_trunc that can return variable increments i.e.: 5, 10, or 15 minutes increments, 3, 4, 6 hour increments, 1, 2 weekly increments, I imagine that the returned values would have to either be the "floor" or "ceiling" of the actual time stamps. Regards, Richard Broersma Jr.
On Sat, Jun 17, 2006 at 13:08:20 -0700, Richard Broersma Jr <rabroersma@yahoo.com> wrote: > I am working with the date_trunc() function with great success especially in the group by clause > for aggregates. > > However, it is limited to returning "WHOLE" time units. i.e. years, months, days, hours, minutes, > seconds. > > Are there any functions similar to date_trunc that can return variable increments i.e.: > > 5, 10, or 15 minutes increments, > 3, 4, 6 hour increments, > 1, 2 weekly increments, > > I imagine that the returned values would have to either be the "floor" or "ceiling" of the actual > time stamps. You might be able to extract the time since the epoch and divide it by the appropiate number of seconds (the length of your interval) and truncate the result. This might have unexpected results for you when you span daylight savings time changes. Another option is to not use timestamp, but rather just store an integer that represents some number of your intervals offset from an epoch.
> > Are there any functions similar to date_trunc that can return variable increments i.e.: > > > > 5, 10, or 15 minutes increments, > > 3, 4, 6 hour increments, > > 1, 2 weekly increments, > You might be able to extract the time since the epoch and divide it by the > appropiate number of seconds (the length of your interval) and truncate > the result. This might have unexpected results for you when you span > daylight savings time changes. > > Another option is to not use timestamp, but rather just store an integer that > represents some number of your intervals offset from an epoch. Bruno, Thanks for the suggestions. I am going to "toy" around with them to see what I can get to work. Thanks for the help. Regards, Richard Broersma Jr.