Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

> DATEDIFF('year', '12-31-2020', '01-01-2021') returns 1 because even though the two dates are a day apart, they've crossed the year boundary.

What is the use of such a function? If I saw this answer I would assume a bug somewhere (until reading the documentation).

View on HN

If I want a table of figures for the past 18 months, I could aggregate them like so:

    GROUP BY DATEDIFF('month', "transaction_date", NOW())

And get a result set that shows the relative month in one column, and the sum in another.

And those values relative values won't change every month like they would if I just grouped by

    EXTRACT('year-month', "transaction_date")

(or whatever the syntax is for that)

Also useful for a stored procedure or view than can then be JOINed in other queries as time goes on.

In PostgreSQL you would group by date_trunc('month', transaction_date)

That would produce dates instead of integers though. I want a table that looks like this:

    MonthsAgo | Sales
    ==================
            4 | 4,500
            3 | 7,204
            2 | 12,578
            1 | 15,748
            0 | 34,485

And maybe use a parameter so the user can go by week, or quarter, or whatever.

The "distance" between two dates seems quite useful. In Postgres there is no need for a datediff() function - you would just subtract the two dates: date '2021-01-01' - date '2020-12-31'

These are used pretty often when doing data analysis. It's a simple way to group things together.

For example, find all users who have have been active at least 10 days. This provides a simple way to do a complex operation (if a user signs up Dec 29, a naive implementation won't catch that their 10 days is in January of the next year).

In that example, what does knowing you've crossed 1 year boundry give you (i.e. gow do you use the numeric result?) And if it does matter why not group by the year?

The point of the function is that it doesn't matter you've crossed the year boundary when counting days.

A naive implementation would accidentally get tripped up by the year -- extracting the 'day' part of a timestamp, as an integer, gives you the day from the start of the year. So on one side of the year boundary you have 365 and on the other you have 1. The way to do it correctly is to multiply the day in the year by the year itself so that a '1' on a later year is a bigger number.

And of course grouping by year isn't always what you want to do :)

My naive implementation would have been to calculate `now() - signup_date > "10 days"::interval`. That doesn't trip over any year bounds, but if you sign up at 4pm then I wouldn't consider you until 4pm on the 10th day. Which makes total sense, but generally isn't how this is done when a human does it by hand.

I feel like cedricd and OP of this chain are talking about different things, or at least it's hard to discern from the conversation.

If you care about Days, you normally absolutely -should- use DATEDIFF('DAY' instead of DATEDIFF('YEAR' and act accordingly. The bigger thing is the semantics they provide.

Frankly, this can be a pain point at times, but IIRC PostgreSQL at least is very work-aroundable, IIRC you can get the equivalent for most common cases off the interval from an add/sub.

Honestly, Dates in SQLite are harder to deal with in the long term, since without a native data type you have to write at least the level of conversions you would in PostgreSQL. (e.x. just convert everything to/from tics at the abstraction layer.)

Edit: Also I would suggest considering instead use of getdate() <= DATEADD('day', signup_date,1) or a variant as that is probably more cross DB friendly

It means “spanned which legal-y periods”, I think. E.g. if a user is billed weekly, billing should ~group 2 weeks, even if login events happened at Sat and Mon. As a former accounting consultant/developer I can guess use cases like “group fixed assets by how many tax amortization quarters they already took part in, and then …”.

Lol my favorite case of this was where an org could by regulation be paid no less than 30 days apart, but could not take more than 1 payment per month, and could not take a payment on Sundays or banking holidays. Solve for X.

Find the minimum and maximum maximum number of consecutive payments this org can take?

> These are used pretty often when doing data analysis.

In my experience you almost always want to count intervals for analysis and not interval boundaries. For example when calculating someone’s age in years.

The use cases for interval boundaries seem to mostly be businesses rules based on contract dates.

Normal subtraction works there so that's not a compelling example at all.

> For example, find all users who have have been active at least 10 days.

Well, then you only need to compare the difference of the timestamp (or date) values with an interval of 10 days. e.g. end_time - start_time >= interval '10 days'

Reply on news.ycombinator.com