Add Single-line date-arithmetic and formatting. Perhaps just as a 3rd or 4th argument to the various conversion functions.
For example: qdate:to_string(Modifier, Format, TZ, Date) This seems messy, since qdate:to_string(Modifer, Format, Date) would be ambiguous with qdate:to_string(Format, TZ, Date).
Alternatively, it could be a simple qdate:math(Modifer, Date), which would return perhaps whatever the original format was (integer() -> integer(), datetime() -> datetime()), with the exception being string() -> datetime().
Modifier would be a proplist that gets evaluated in order:
[
{day, 5},
{hour, -1},
]
Add 5 days, then subtract an hour.
This could, given Daylight Saving Time, be different if the hour was first decremented, then he days were added.
Generally, Hours, Minutes, and Seconds will be added based on their conversion to seconds and added to the unixtime, whereas Dates, Months, and years will be added to the erlang date 3-tuple.
Add Single-line date-arithmetic and formatting. Perhaps just as a 3rd or 4th argument to the various conversion functions.
For example:
qdate:to_string(Modifier, Format, TZ, Date)
This seems messy, sinceqdate:to_string(Modifer, Format, Date)
would be ambiguous withqdate:to_string(Format, TZ, Date)
.Alternatively, it could be a simple
qdate:math(Modifer, Date)
, which would return perhaps whatever the original format was (integer() -> integer(), datetime() -> datetime()), with the exception being string() -> datetime().Modifier would be a proplist that gets evaluated in order:
Add 5 days, then subtract an hour.
This could, given Daylight Saving Time, be different if the hour was first decremented, then he days were added.
Generally, Hours, Minutes, and Seconds will be added based on their conversion to seconds and added to the unixtime, whereas Dates, Months, and years will be added to the erlang
date
3-tuple.