ArangoDB is a multi-purpose, open-source database with flexible data models for documents, graphs, and key-values. Build high performance applications using a convenient SQL-like query language or JavaScript/Ruby extensions. Use ACID transaction if you require them. Scale horizontally and vertically with a few mouse clicks.
add or subtract a given amount of time units from date. Amount may also be an ISO duration, but unit must then be left out.
TODO: discuss if mixed-sign ISO durations are useful enough to be added, add support for weeks unit?
DATE_DIFF(date1, date2, unit):
Calculate difference between two dates, in a given time unit, optionally with decimal fraction.
TODO: Testing (years and months as expected?), assess time unit naming (singular / plural, ms as alternative abbreviation of f?)
Additional DATE_*() functions:
TODO: Assess usefulness of functions like "is birthday", "last day of month/week"...
Favor generic solutions, so that AQL queries stay semantically meaningful even if the functions are used differently than anticipated. Counter example: DATE_IS_BIRTHDAY(DATE_ADD(date, 7, "days")) to compare month and day (better would be: DATE_PART(), DATE_MATCH() or DATE_COMPARE()). DATE_DAYS_IN_MONTH(date) (28..31)?
Compare two dates partially, using a range of units (e.g. "months", "hours" to compare months, days and hours, while ignoring years, seconds and ms.
TODO: Should it handle leap days, because leaplings deserve a birthday party every year, or is it up to the user to handle leap years in combination with birthdays? We could substitute Feb 29th automatically with 28th or March 1st, but it may be undesired for use cases other than birthday checking. It also depends on the local jurisdiction which day is the birthday in non-leap years.
DATE_FORMAT(date, format):
Format a date according to format string.
TODO: Use LRU cache for ISO durations to limit the maximum number of cache entries.
The current cache object never goes out of scope (as far as I understand), and the cache will thus grow unbounded. This is a problem in server-side JS, because the server may run for a year straight. But it's also a security risk, because an attacker can easily make the server claim a lot of memory without releasing it again (memory leak), until the server or other processes crash as the system runs out of memory. Cache is cleared on every AQL query thanks to Jan.