Upgrade to time 0.3 #1455

paolobarbolini · 2021-09-24T10:48:15Z

Continuation of #1444

Still left to do:

Fix a solution for How to deal with multiple versions of `time` when using macros time-rs/time#356
Update documentation

paolobarbolini · 2021-10-01T05:31:30Z

It doesn't look like macros like it when time is renamed, since they all import it with ::time
https://github.com/time-rs/time/blob/d700977ce9bc34013ee9841e122edbc807f410e4/time-macros/src/datetime.rs#L47

Any ideas?

abonander · 2021-10-01T20:50:52Z

Can we get around using the macros?

paolobarbolini · 2021-10-09T09:14:24Z

Can we get around using the macros?

We could but first I'm trying to see if there are other solutions time-rs/time#356 (reply in thread)

abonander · 2021-11-03T01:13:04Z

@paolobarbolini sounds like a solution wasn't forthcoming there. I dunno how feasible it is to try to get time to add a crate parameter to its macros, sounds like it might get stuck in bikeshedding.

Can we just inline the output of the macros here? It seems like it should be relatively stable as the code that format_description!() outputs doesn't appear to use any hidden types or fields.

kyle-mccarthy · 2021-11-03T03:04:21Z

I am not familiar with this issue and am not sure the circumstances are the same, but is the method used by the postgres-types crate possible? It looks like they also rename the time crate.

paolobarbolini · 2021-11-03T05:49:32Z

@paolobarbolini sounds like a solution wasn't forthcoming there. I dunno how feasible it is to try to get time to add a crate parameter to its macros, sounds like it might get stuck in bikeshedding.

Can we just inline the output of the macros here? It seems like it should be relatively stable as the code that format_description!() outputs doesn't appear to use any hidden types or fields.

I suggested it but they don't seem too convinced about it time-rs/time#356 (reply in thread)

I'll try inlining the macro output.

I am not familiar with this issue and am not sure the circumstances are the same, but is the method used by the postgres-types crate possible? It looks like they also rename the time crate.

That's what we're doing too

kyle-mccarthy · 2021-11-03T06:58:55Z

@paolobarbolini sorry, I didn't link to the correct spot. I meant with how they declare time as an extern crate.

Doing something similar, I was able to run cargo check --manifest-path sqlx-core/Cargo.toml --no-default-features --features offline,all-databases,all-types,migrate,runtime-async-std-native-tls without errors.

The specific changes I made can be viewed here: kyle-mccarthy@005d922

paolobarbolini · 2021-11-03T07:09:21Z

@paolobarbolini sorry, I didn't link to the correct spot. I meant with how they declare time as an extern crate.

Doing something similar, I was able to run cargo check --manifest-path sqlx-core/Cargo.toml --no-default-features --features offline,all-databases,all-types,migrate,runtime-async-std-native-tls without errors.

The specific changes I made can be viewed here: kyle-mccarthy@005d922

Interesting, I didn't know extern crate had the power to rename a crate like that.

paolobarbolini · 2021-11-03T07:16:39Z

I cherry-picked your commit @kyle-mccarthy. I got a warning that the #[macro_use] wasn't necessary, so I tried removing it.

abonander · 2021-11-03T19:42:44Z

sqlx-core/src/lib.rs

@@ -104,3 +104,6 @@ pub mod mssql;
 /// sqlx uses ahash for increased performance, at the cost of reduced DoS resistance.
 use ahash::AHashMap as HashMap;
 //type HashMap<K, V> = std::collections::HashMap<K, V, ahash::RandomState>;
+
+#[cfg(feature = "time-03")]
+extern crate time_03 as time;


Can we make this conditional on feature = "postgres" as well? It should fix those "unused" warnings.

Or nevermind this if you're still working on support for MSSQL/SQLite

Honestly I just tested postgres. I haven't looked into mysql and sqlite, I just fixed the compiler warnings 😄. From a quick search it looks like support for time in sqlite hasn't been implemented yet!? https://github.com/launchbadge/sqlx/tree/master/sqlx-core/src/sqlite/types

It definitely looks to be that way, I guess no one's ever asked for it. I guess don't worry about SQLite then?

So yeah, whatever suppresses the warning works for me.

abonander · 2021-11-03T19:43:34Z

I am absolutely ecstatic that this just works! This is a backwards-compatible change too, isn't it? So we could release this with 0.5.10 instead of 0.6.0

abonander · 2021-11-12T22:56:29Z

@paolobarbolini do you think you'll be able to finish this soon?

paolobarbolini · 2021-11-13T13:28:02Z

@paolobarbolini do you think you'll be able to finish this soon?

Yes, I'll look into it next week.

abonander

Couple remaining nits:

can we fix the warnings on the extern crate time_03 as time; in sqlx-core/src/lib.rs when it's not being used?
it looks like the existing type tests for time 0.2 were repurposed to test the types from time 0.3 which leaves the former with no type tests, can we make sure to cover both?

paolobarbolini · 2021-11-25T11:27:33Z

it looks like the existing type tests for time 0.2 were repurposed to test the types from time 0.3 which leaves the former with no type tests, can we make sure to cover both?

Ah right. I'll look into it

paolobarbolini · 2021-12-02T10:07:16Z

I'm trying to do point 2 but we're again running into the same problem we had before with both time 0.2 and time 0.3 macros importing time as ::time, which doesn't work because we can have only one version imported with the name time.

paolobarbolini · 2021-12-06T09:14:19Z

It seems to me like these macro issues are going to come up again when time 0.4 comes out. Just to get an idea I looked at the downloads for the latest 0.2 ¹ and 0.3 ² versions and between the two time 0.3 only makes ~30% of the downloads 😞. I kinda wished everybody updated so we didn't have to do this.

paolobarbolini · 2021-12-06T10:06:24Z

Also I just realized the sqlx-macros optional feature suggestion system should be updated to support both versions 😅

abonander · 2022-01-03T20:37:03Z

@paolobarbolini should we just bite the bullet and upgrade to time 0.3 wholesale in 0.6? Might push people to upgrade.

paolobarbolini · 2022-01-10T09:29:14Z

@paolobarbolini should we just bite the bullet and upgrade to time 0.3 wholesale in 0.6? Might push people to upgrade.

👍 I removed all of my changes and rebased the original author's changes on top of master

tyhi · 2022-01-10T18:22:08Z

It might be worth to update the time version from 0.3.2 to 0.3.5, that would change MSRV 1.48 -> 1.51.

abonander · 2022-01-10T18:26:06Z

Officially, we only support the latest stable version of Rust. I try to avoid using language or library features that are too new but MSRV just isn't something we keep track of on this project. Should probably add a disclaimer somewhere visible for that.

thomaseizinger · 2022-01-11T23:13:53Z

It might be worth to update the time version from 0.3.2 to 0.3.5, that would change MSRV 1.48 -> 1.51.

This is a lib (hence no Cargo.lock) so unless we pin it with =0.3.2 in the manifest, the upgrade from 0.3.2 to 0.3.5 will transparently happen in the consumer binary.

happysalada · 2022-02-16T19:26:23Z

very interested in this!
It would make the move from chrono to time, much simpler.
Another potential addition, would it make sense to add the time feature serde-human-readable by default?
Without this, all the time structs are not serializable and deserializable
here is the reference https://github.com/time-rs/time/blob/main/Cargo.toml#L36
Or perhaps this should be put behind the crate's serde feature flag

paolobarbolini · 2022-02-16T20:06:25Z

Another potential addition, would it make sense to add the time feature serde-human-readable by default? Without this, all the time structs are not serializable and deserializable here is the reference https://github.com/time-rs/time/blob/main/Cargo.toml#L36 Or perhaps this should be put behind the crate's serde feature flag

The time crate docs say Libraries should never enable this feature, as the decision of what format to use should be up to the user

https://docs.rs/time/0.3.7/time/index.html#feature-flags

abonander · 2022-02-16T20:28:14Z

Even if we wanted to enable the feature by default, which we don't for the reason @paolobarbolini stated, I have to question time's choice for their human-readable serialization format, which appears to be:

<year>-<month>-<day> <hours>:<minutes>:<seconds>.<seconds-fraction> <offset>

Which is ever so close to being ISO-8601/RFC 3339 compliant but I believe the space separator for the offset breaks it.

abonander · 2022-02-16T20:48:02Z

Indeed, it produces dates like

2022-02-16 20:30:08.33839334 +00:00:00

which are rejected by Javascript's Date.parse(), something we use a lot on the frontend. It's perhaps accepted by more permissive parsers like https://dencode.com/en/date/iso8601 which interpreted the above date just fine somehow, but not stricter ones. It's similarly rejected by Dart's DateTime.parse(), which we use in our Flutter-based mobile app projects.

You can enable RFC-3339 serialization, but you have to mark every time::OffsetDateTime field with #[serde(with = "time::serde::rfc3339")], which uses the serde-well-known feature, not the serde-human-readable feature.

The reasoning for the choice is explained here: time-rs/time#248 (comment)

I don't see why RFC 3339 couldn't have been the default since it's generally more useful for most of the places you'd actually use time with the custom extended-range format being enabled via #[serde(with)], but it's a closed matter anyway.

happysalada · 2022-02-17T03:52:38Z

Thanks for the comments and the correct way to serialize with serde (it all makes sense now).
Looking forward to 0.6!

kevinbader · 2022-04-03T16:54:17Z

sqlx-core/Cargo.toml

@@ -151,7 +151,7 @@ sha-1 = { version = "0.9.8", default-features = false, optional = true }
 sha2 = { version = "0.9.8", default-features = false, optional = true }
 sqlformat = "0.1.8"
 thiserror = "1.0.30"
-time = { version = "0.2.27", optional = true }
+time = { version = "0.3.2", features = ["macros", "formatting", "parsing"], optional = true }


Wouldn't #[serde(with = "time::serde::rfc3339")] (as described in this comment) require the serde-well-known feature flag? Since serializing with RFC3339 format is a very common use case, I guess adding serde-well-known would make sense...

Generally you don't want to enable feature flags you don't strictly need. That would force that feature on for all crates that depend on SQLx.

Makes sense... but what is then the recommended way to read a timestamp from the database and put it into a DTO in RFC3339 format? Since the version of time that sqlx comes with doesn't support this (due to version and that feature flag), a user of sqlx has to use an intermediate "DatabaseDTO" with sqlx::types::time::OffsetDateTime for fetching from the database (using query_as), just to then convert it manually into an "ActualDTO" with time::OffsetDateTime (I did that with time::OffsetDateTime::from_unix_timestamp(db_dto.created_at.unix_timestamp()), but I'm not sure that's the best way). Only then the aforementioned way to serialize a timestamp using RFC3339 with with actually works. Or am I missing something?

That's only an issue because SQLx is currently using a different version of time than you are. Otherwise sqlx::types::time::OffsetDateTime and time::OffsetDateTime should always refer to the same type.

time::serde::rfc3339 exists since time v0.3.6, so it's not available in the version proposed in this PR (which means serde-well-known would only make sense when using >= 0.3.6 anyway; before that, there is no such feature flag).

I get that enabling too many features is not a good idea as it would impact lots of users. But what about going with a more recent version of time, i.e., >=0.3.6? That would make it easier for anyone trying to include timestamps in REST API responses :)

time::serde::rfc3339 exists since time v0.3.6, so it's not available in the version proposed in this PR

sqlx depending on 0.3.2 means versions >=0.3.2, <0.4.0 are allowed, so you're free to use features from newer patch versions of the time crate

The version specified here is not restrictive and Cargo will automatically pull in the latest 0.3.x release if it's not in your Cargo.lock already when building your crate.

You should also specify time = { version = "0.3.6", features = ["serde-well-known"] } in your own dependencies to be certain of this.

DeliciousHair mentioned this pull request Oct 14, 2021

Additional DB refactoring get10101/itchysats#314

Closed

4 tasks

malobre mentioned this pull request Nov 2, 2021

feature(sqlx-core): Add support for time 0.3 #1522

Closed

abonander reviewed Nov 3, 2021

View reviewed changes

abonander mentioned this pull request Nov 9, 2021

Update BigDecimal dependency #1529

Merged

abonander requested changes Nov 23, 2021

View reviewed changes

Update time to 0.3.2

8b1d812

paolobarbolini force-pushed the time-0.3.2 branch from b4eef14 to 8b1d812 Compare January 10, 2022 09:27

abonander mentioned this pull request Jan 11, 2022

time dependency out of date #1277

Closed

abonander added this to the 0.6.0 milestone Feb 16, 2022

paolobarbolini mentioned this pull request Mar 13, 2022

Consider upgrading time crate to 0.3 #1749

Closed

kevinbader reviewed Apr 3, 2022

View reviewed changes

seanpmyers mentioned this pull request Apr 4, 2022

Bump time from 0.2.27 to 0.3.9 in /application seanpmyers/loremaster#18

Closed

Merge branch 'master' into time-0.3.2

8dff21d

leebenson mentioned this pull request Apr 11, 2022

OutputType is not implemented for PrimitiveDateTime async-graphql/async-graphql#887

Closed

abonander mentioned this pull request Apr 12, 2022

Request for Comments: Possible Strategies for Public Dependency Version Management #1796

Closed

abonander merged commit ba123e6 into launchbadge:master Apr 14, 2022

Upgrade to time 0.3 #1455

Upgrade to time 0.3 #1455

Conversation

paolobarbolini commented Sep 24, 2021 • edited Loading

paolobarbolini commented Oct 1, 2021 • edited Loading

abonander commented Oct 1, 2021

paolobarbolini commented Oct 9, 2021

abonander commented Nov 3, 2021

kyle-mccarthy commented Nov 3, 2021

paolobarbolini commented Nov 3, 2021

kyle-mccarthy commented Nov 3, 2021 • edited Loading

paolobarbolini commented Nov 3, 2021

paolobarbolini commented Nov 3, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paolobarbolini Nov 3, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abonander commented Nov 3, 2021

abonander commented Nov 12, 2021

paolobarbolini commented Nov 13, 2021

abonander left a comment • edited Loading

Choose a reason for hiding this comment

paolobarbolini commented Nov 25, 2021

paolobarbolini commented Dec 2, 2021

paolobarbolini commented Dec 6, 2021

Footnotes

paolobarbolini commented Dec 6, 2021

abonander commented Jan 3, 2022

paolobarbolini commented Jan 10, 2022

tyhi commented Jan 10, 2022

abonander commented Jan 10, 2022

thomaseizinger commented Jan 11, 2022

happysalada commented Feb 16, 2022

paolobarbolini commented Feb 16, 2022

abonander commented Feb 16, 2022

abonander commented Feb 16, 2022

happysalada commented Feb 17, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paolobarbolini commented Sep 24, 2021 •

edited

Loading

paolobarbolini commented Oct 1, 2021 •

edited

Loading

kyle-mccarthy commented Nov 3, 2021 •

edited

Loading

paolobarbolini Nov 3, 2021 •

edited

Loading

abonander left a comment •

edited

Loading