Less-used temporal methods: candidates for removal / migration

[MarcoGorelli]

I'd like to suggest removing some less-used temporal methods to slim down the main Polars package and API a bit. Happy to maintain these long-term in polars-xdt if people agree.

Strong candidates (IMO):

• base_utc_offset
• dst_offset

~Debatable:~

• ~month_start and month_end (I could then add quarter_end, year_end, week_end, ...)~
• ~is_leap_year~
• ~combine~

[stinodego]

I found combine to be extremely useful. I believe I requested it at the time. And I've never done anything fancy with datetimes. Combining date/time columns into a datetime is a common enough operation.

The other 'debatable' ones I also think are valuable enough.

Not sure about the 'strong candidates'.

[ritchie46]

Let's wait a bit. I don't think they hurt us at the moment. Let's also put them in polars-xdt. Once we see that that will get the familiarity it then deserves we can move logic.

Open to host polars-xdt under the polars org?

[MarcoGorelli]

Sounds good, I'm not sure where to draw the line between 'core' and 'plugin'

The two 'strong candidates' - one came from https://stackoverflow.com/questions/76578147/dst-temporal-feature-from-timestamp-using-polars, then other from a comment there. If those two requests had come in today, I think the response would be "plugin!", but at the time I don't think there was that option

Is there a way to see how much traffic each docs page gets? That may give a better idea of how widely they're being used

Open to host polars-xdt under the polars org?

if you're happy with that, then yeah, totally!

[ritchie46]

Yeap, at that time there wasn't.

if you're happy with that, then yeah, totally!

Cool, I will set this up. I will set you as the maintainer. We have to be careful, as we don't want to lose github stars. I will follow up on this.

[alexander-beedie]

Don't forget that time series are an important core function these days - I wouldn't look to move all of this outside the mainline package (especially given that it's already there). Anything that isn't in the core package is a potential barrier to entry, as most people just don't go hunting for things that aren't available by default.

I'd also look to go the other way sometimes; I suspect moving business day functionality into the main package would actually be a very popular move, for example 🤣

FYI: combine gets a dedicated shout-out in Modern Polars, and is likely quite widely used (it's a first-class python datetime method too) ;)

[MarcoGorelli]

Thanks all for your inputs!

Agree on combine, it was a bad suggestion of mine. Keeping it in Polars, I've crossed it out of the suggestion (along with the other ones in the "debatable" section).

I'd still like to make the case that

• base_utc_offset
• dst_offset

aren't broadly useful enough for the main Polars API and are candidate for migration. I'd be surprised if even .001% of users were using them, and as of #12204, I think they're even less useful

Regarding discoverability - polars-xdt is in the pola-rs org now, which should help on that front https://github.com/pola-rs/polars-xdt

[stinodego]

I think both of those are useful enough.

[MarcoGorelli]

ok sure, happy to let this drop then, thanks all!