Moaaz Assali <ma5679@nyu.edu> writes:
> The date_bin() function has a bug where it returns an incorrect binned date
> when both of the following are true:
> 1) the origin timestamp is before the source timestamp
> 2) the origin timestamp is exactly equivalent to some valid binned date in
> the set of binned dates that date_bin() can return given a specific stride
> and source timestamp.
Hmm, yeah. The "stride_usecs > 1" test seems like it's a partial
attempt to account for this that is probably redundant given the
additional condition. Also, can we avoid computing tm_diff %
stride_usecs twice? Maybe the compiler is smart enough to remove the
common subexpression, but it's a mighty expensive computation if not.
I'm also itching a bit over whether there are integer-overflow
hazards here. Maybe the range of timestamp is constrained enough
that there aren't, but I didn't look hard.
Also, whatever we do here, surely timestamptz_bin() has the
same problem(s).
regards, tom lane