Somebody claiming to be "IQ Support Team" wrote:
Suggesting addition of two new modifiers to SQLITE Date Time functions.
Add new modifier(14):javams and modifier(15):javanano similar to
unixepoch modifier but extended to support milliseconds and
nanoseconds.
This seems like an application-level feature.
If it were to go into SQLite, then I have a few questions:
1. Should the nanoSecond and milliSecond resolution time functions take
into account the gradual slowing of Earth's rotation as reflected in
occasional leap-Seconds?
2. Does anybody actually keep times with such high resolution where they
are simultaneously concerned with converting to day-of-month,
month-of-year and the like?
These questions arise from observing that SQLite's time functions are
useful mainly for their conversions between time-into-era numbers and
more people-friendly forms. The only reason I see to stack this higher
resolution functionality onto the existing functionality is to achieve
some efficiency that would be less practical with the implementation
split between SQLite and application code. However, since anybody can
#define SQLITE_OMIT_DATETIME_FUNCS during a build, and use their more
specialized (or accurate) functions instead, this efficiency concern
seems misplaced.
If the SQLite developers were to undertake this enhancement, it should
certainly come with another #define to chop out the extra code it would
entail. (SQLITE_APPROXIMATE_TIME?)
Since you (Mr. Team) have apparently already created this much more
accurate set of conversions, perhaps you could offer them as a plug-in
replacement for the readily omitted functions.
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
