feat(api): add DateValue.epoch api for computing days since epoch

[cpcloud]

Description of changes

Adds DateValue.epoch method and underlying ops.UnixDate.

This was originally meant to help with window function queries with range
bounds where the backend doesn't support intervals in preceding/following, but
I think it has general utility and is much more clear IMO than casting a
date value to an integer.

[gforsyth]

Propose to codify the word uxfail as you've implicitly defined it above.

[jcrist]

Is this operation semantically the same as date_col.delta(ibis.date(1970, 1, 1), "d")? If so, is there a reason why that's insufficient? We might even add an ibis.epoch() function that's effectively an alias for ibis.date(1970, 1, 1) in this context. I find the delta spelling a bit easier to understand just from looking at it.

Alternatively, could we spell this as epoch_days() (to match the existing epoch_seconds)? I find the epoch() method to be a bit confusing, since it's not clear to me from the name alone what it's referencing (days_since_epoch would be even clearer, but 🤷).

[cpcloud]

Is this operation semantically the same as date_col.delta(ibis.date(1970, 1, 1), "d")? If so, is there a reason why that's insufficient? We might even add an ibis.epoch() function that's effectively an alias for ibis.date(1970, 1, 1) in this context. I find the delta spelling a bit easier to understand just from looking at it.

It's not insufficient, just more verbose than I'd like.

Alternatively, could we spell this as epoch_days() (to match the existing epoch_seconds)? I find the epoch() method to be a bit confusing, since it's not clear to me from the name alone what it's referencing (days_since_epoch would be even clearer, but 🤷).

epoch_days seems reasonable and keeps consistency with epoch_seconds.

My original plan was to have epoch on DateValue and TimestampValue (with the latter having a unit parameter) but I think three separate methods epoch_secs/epoch_millis/epoch_micros is probably better (with an eventual epoch_seconds deprecation).

[jcrist]

Overall happy with the user-facing API, just a few comments on the implementation.

[jcrist]

I actually find reading these in the sqlglot dialect harder to understand than the previous version in the compiler. These are pretty complicated implementations (length-wise), doing more in the dialect means we have additional places to check for complex logic when trying to understand how something is compiled (compiler, rewrite rules, our dialects.py file, sqlglot's dialects, sqlglot's rewrite rules). If possible, I'd find it easier to understand compilation if we try to keep most of our implemented logic in the compiler itself rather than the dialects here.

Just a -0.25 though, if you feel strongly about doing it this way then that's fine.

[cpcloud]

Unfortunately without these (or something like it), it's a non-starter to implement this without using a new operation. Happy to try the no-new-op route, but to do that we need sqlglot to correctly compile DateFromParts correctly for all the backends it can, which requires porting the previous code to this.

[cpcloud]

In general I agree with your point, but this happened to be an annoying case where it seemed better to centralize this logic in sqlglot rather than repeating in the compiler.

[jcrist]

LGTM! Leaving the merge to you - I assume you want to squash some/all of these commits.