We should consider adding support for common date manipulation operations:

• DATE_ADD(part, count, date): Offset date by count bins of type part. Example: DATE_ADD('month', 2, #2020-04-28#) => #2020-06-28#.
• DATE_DIFF(part, date1, date2): Count the number of bin boundaries of type part between date1 and date2. Example: DATE_DIFF('year', #2020-01-15#, #2019-12-05#) => 1.
• DATE_SUB(part, date1, date2): Count the number of complete bins of type part between date1 and date2. Example: DATE_SUB('year', #2020-01-15#, #2019-12-05#) => 0.
• DATE_NAME(part, date): Return the text representation of the bin of type part for date. Example: DATE_NAME('month', #2020-04-28#) => 'April'.
• DATE_PARSE(format, string): Convert string to a timestamp using format.

Date arithmetic can also be implemented using interval types, but it could be helpful to have function implementations in the short term if the implementation of interval types is going to be some time.

We have a choice of parsing syntax here, including the Postgres and ICU formats. The Postgres format is more complete in some ways as it supports ordinal dates (e.g. July 14th), but it would require cloning or importing the formatting code. The ICU format is slightly more limited, but can support non-Gregorian calendars and we have already committed to using some parts of the the ICU library for collation, and discussions have started around using ICU Time Zone support, so we could get the functionality "for free".

Converting scalars to text via functions like DATE_NAME or the Postgres to_str is not usually a good idea as it can lead to performance degradation and non-portability of queries when employed by naïve users, but such functions have been traditionally provided by database systems since the 1970s (when the output of the query was the report instead of just the data for the report) so we probably need to support them.