Add optional time crate support for apalis-sql

[Himmelschmidt]

I want to use sqlx with the time crate but apalis-sql hardcodes chrono. I added time crate support as an optional feature in my fork - chrono stays as the default so it's fully backwards compatible.

This would require changes in at least apalis-postgres (that's what I use). Are there other parts of the project that would need updating too?

Would you be open to a PR for this?

[geofmureithi]

There was a time we tried to support both time and chrono and it was a mess. This might have been because we had a monorepo. Since we have split the repos, it may be easier to manage. I am not sure this should go to apalis-sql though (we can use generics on apalis-sql) but rather the specific implementations eg apalis-postgres. I am open to thinking more about this. Is there a specific reason you need sqlx with time?

[geofmureithi]

Here is the PR in question:
#185

[Himmelschmidt]

My reason for wanting it is the same reason addressed in the original PR:

This is useful for users who are already working with sqlx and time, bc sqlx doesn't allow you to use chrono and time together

[geofmureithi]

@Himmelschmidt Understandable. This would need to be done in phases as there are 3 crates using sqlx. I would want to avoid having either deps (chrono/time) in apalis-sql. The goal for apalis-sql is to grow to be usable beyond sqlx. WDYT?

[geofmureithi]

This was possibly the mistake:

#[cfg(feature = "chrono")]
type Timestamp = chrono::DateTime<chrono::Utc>;
#[cfg(feature = "time")]
type Timestamp = time::OffsetDateTime;

We may want to use a trait but this may need a little more thinking.

This crate might be a reference to what we need to do.

[Himmelschmidt]

This is very similar to how I did it in my branch, I'll try to look into a bit more to see how else it could be done

[Himmelschmidt]

What was the problem with this approach?

[geofmureithi]

There was no specific problem. The OP of the other PR just did the PR without looking at this first.

[geofmureithi]

@Himmelschmidt Please look at apalis-dev/apalis-postgres#35 and give some feedback

[Himmelschmidt]

I just opened PRs #654 , apalis-dev/apalis-mysql#14 , apalis-dev/apalis-postgres#38 , apalis-dev/apalis-sqlite#29

I did local paths for the crates while I was working on it. I guess I can make the edits once the apalis-sql is merged? Let me know if this was completely not in the direction you had hoped.

[Himmelschmidt]

I've actually gone ahead and converted them to drafts for now, as I'm taking a second look and really don't like how this turned out.

The cleanest way I see to do it is to have the conditional compilation and trait fully in apalis-sql and have the others just use apalis-sql with whatever feature they want. Because of the orphan trait rule, I really don't see a cleaner way to do this.

Do you have any thoughts?

I would want to avoid having either deps (chrono/time) in apalis-sql

How important is this requirement to you?

[geofmureithi]

How important is this requirement to you?

I would prefer a solution that doesnt add deps to apalis-sql because the longterm goal of apalis-sql is to expand to support more than sqlx. I would want to create apalis-diesel and that would not do too well with an sqlx requirement. I can accept a feature flag of chrono/time in apalis-sql.

[geofmureithi]

I've actually gone ahead and converted them to drafts for now, as I'm taking a second look and really don't like how this turned out.

@Himmelschmidt What is wrong with the implementation? I thought it looked OK. What dont you like about it?

[Himmelschmidt]

I went with the trait approach but then I couldn't implement anything in the individual subcrates. Too much boiler plate, I think I have a much simpler solution, I'll have a pr soon

[Himmelschmidt]

@geofmureithi is there a specific reason apalis-mysql has datetime columns instead of timestamp? Not very familiar with MySql and I'm having issues with my initial approach. That is: all chrono/time conditional compilation happens in apalis-sql. The downstream crates each just need to import the type and ext

[geofmureithi]

I think you should be able to write migrations to the type you want. There is no specific reason AFAIK

…

On Fri, 26 Dec 2025, 18:18 Himmelschmidt, ***@***.***> wrote: @geofmureithi <https://github.com/geofmureithi> is there a specific reason apalis-mysql has datetime columns instead of timestamp? Not very familiar with MySql and I'm having issues with my initial approach. That is: all chrono/time conditional compilation happens in apalis-sql. The downstream crates each just need to import the type and ext — Reply to this email directly, view it on GitHub <#649 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWXVRGVQ2WMRHFJAJVGZO4L4DVGVZAVCNFSM6AAAAACPQQPEZSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZUG42TCNA> . You are receiving this because you were mentioned.Message ID: ***@***.***>