John said:
Plus one day... overreliance on the implementation, of course!
Cleaner would be
Agreed
Your idea would be fine if you can count on no data DURING the last
second - date/time values can contain sub-second data but not display
it.
The way I see it, sub-second datetime values are not supported by Jet's
temporal functions (e.g. DATEPART) so by going outside of the supported
functionality you would either have to go it on your own (e.g. write
your own temporal functions) or put up with rounding (banker's rounding
for datetime values <g>?!) which could be acceptable e.g.
where 0.000011574074074074074074 (decimal) is one second in DATETIME
representation:
SELECT DATEPART('d',
#2006-01-01 23:59:59#
+ (0.49 * 0.000011574074074074074074)
)
is 1 (rounds down),
SELECT DATEPART('d',
#2006-01-01 23:59:59#
+ (0.50 * 0.000011574074074074074074)
)
is 1 (rounds down),
SELECT DATEPART('d',
#2006-01-01 23:59:59#
+ (0.51 * 0.000011574074074074074074)
)
is 2 (rounds up).
Personally, I use CHECK constraints (validation rules) on my DATETIME
columns to ensure they are of one second granularity e.g.
CREATE TABLE Test (
test_date DATETIME NOT NULL,
CONSTRAINT test_date__one_second_granularity
CHECK (
test_date =
DATESERIAL(YEAR(test_date), MONTH(test_date), DAY(test_date))
+ TIMESERIAL(HOUR(test_date), MINUTE(test_date), SECOND(test_date))
)
);
with helper functions to remove (round) subsecond elements e.g.
CREATE PROCEDURE TestProcAdd (
arg_date DATETIME
) AS
INSERT INTO Test (test_date)
SELECT DISTINCT
DATESERIAL(YEAR(arg_date), MONTH(arg_date), DAY(arg_date))
+ TIMESERIAL(HOUR(arg_date), MINUTE(arg_date), SECOND(arg_date))
AS test_date
FROM Test;
Jamie.
--