profile
viewpoint
Jacob Pratt jhpratt Syracuse-area, NY, USA jhpratt.dev CS @ Potsdam | Seeking employment for after graduation | Creator and maintainer of time and standback | Contributor to a number of open-source projects

r-spacex/SpaceX-API 6963

:rocket: Open Source REST API for rocket, core, capsule, pad, and launch data

jhpratt/darksky-api 3

Ruby gem to make easy requests to the DarkSky API

jhpratt/python-vote-core 3

Python libraries for various electoral methods

jhpratt/skrolr 3

Lightweight JavaScript / TypeScript library that makes creating dynamic scrollers easy

jhpratt/crev-proofs 0

Crev proof repository

jhpratt/esfetch 0

Modernized drop-in replacement for fetchival

issue commenttime-rs/time

Time v0.3 tracking issue

As a breaking release, I think the time::Result type should be made pub(crate) as it clashes with std::result::Result and forces user to re-import it.

jhpratt

comment created time in 12 hours

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

Yeah, that's the theory and when it works, it's nice. When it doesn't it's a bit nasty: now you have 300 minor versions updated and figuring out which one didn't respect semver properly can be tricky.

ffactory-ofcl

comment created time in 4 days

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

I'm not an expert but if your project breaks when you run cargo update, doesn't that mean you may need to fix your Cargo.toml? 🤔 cargo update just updates the Cargo.lock to the newest versions and if Cargo.toml has the correct versions, a clean install & cargo run should work (and thus cargo update on an existing install should work too)

ffactory-ofcl

comment created time in 4 days

push eventtaiki-e/const_fn

Taiki Endo

commit sha 307f500f9b9b3f303b480412b3d4986e5467a47f

Use default community health files

view details

push time in 4 days

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

version_check is the dependency you need to update, since you don't want to update everything for some reason.

Lovely, thank you. Generally big projects wants to avoid blanket cargo update to avoid random breakage.

ffactory-ofcl

comment created time in 4 days

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

So the bug is in a transient dependency? If I want to avoid a blanket cargo update, which dependency do I need to update?

ffactory-ofcl

comment created time in 4 days

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

Had 2.2.23 somewhere in my cargo tree as well but after cargo update everything worked.

ffactory-ofcl

comment created time in 4 days

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

That function used to be private before I created a PR a while back making it (and similar methods) public.

Is this in a released version somewhere? I have time = "0.2" in my Cargo.toml and it picks up v0.2.23 which fails as reported here (rustc 1.49.0-nightly (a9cd294cf 2020-10-22) on macos).

ffactory-ofcl

comment created time in 4 days

push eventtaiki-e/const_fn

Taiki Endo

commit sha ca1f01bc9ebc6126f4c4f1a2ca8d0250f9b71b6d

scripts: Update check-minimal-versions.sh

view details

Taiki Endo

commit sha e964cf828f974bcbbf6a5777ca2d3c9439ce0c5c

Remove homepage field from Cargo.toml This is currently the same as repository field and there is not much point in having it.

view details

push time in 4 days

push eventtaiki-e/const_fn

Taiki Endo

commit sha efdbac474aba1c06f5cb5c32a1199450d64f0bc0

scripts: Mark publish.sh as executable

view details

push time in 6 days

push eventtaiki-e/const_fn

Taiki Endo

commit sha 8a83fd9b5abd05d272c3689e71fb3b68fcc57c60

scripts: Add a script that automates the local side release step This script is still tentative, but it's what I use in all my projects and rust-lang/futures-rs. See also note in the script.

view details

Taiki Endo

commit sha e7366f707eba156dd2bb795a548b3564ac2a685b

Update rustfmt.toml

view details

push time in 6 days

issue commenttime-rs/time

Time v0.3 tracking issue

I'm not sure if you ran across this, but PrimitiveDateTime is an OffsetDateTime without the UtcOffset. There is the ability to assume an offset on the former, which returns the latter. A PrimitiveDateTime has no way to directly get the "current" time, as doing so inherently requires an offset (which isn't present).

The PrimitiveDateTime::assume_* methods make indeed more sense now. So, OffsetDateTime are created from the "current" time and if the system does not support retrieving the local time it will return an error on the local methods. Is that correct?

For the top level documentation short lists for features, goals, non-goals, roadmap etc. could help without writing too much. Otherwise, I think the corrections you made to my comment could be a good starting point for documentation.

jhpratt

comment created time in 7 days

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

I can understand @jhpratt unwillingness to introduce an unsafe block into the code and thereby unnecessarily affect other platforms than *nix. I personally have been bitten by this issue in production, because, as surmised, I did not handle the error correctly. I would also say however, that it took me by surprise that a patch release would introduce said behaviour for *nix targets (effectively disabling the possibility to obtain the local offset).

Perhaps an update of the documentation that marks the function in question as basically "non-functional" on *nix targets would prevent other users to run into this issue until a fix is found?

puetzp

comment created time in 7 days

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

Realistically? The odds are damn near zero.

No, we ran into this problem in production environment, but we used chrono instead of time.

puetzp

comment created time in 7 days

issue commenttime-rs/time

Time v0.3 tracking issue

I don't know if that is the correct issue for this but it seems you're looking for feedback on the API, so I will just dump my thoughts here. The reason I am checking out this crate is that I want update an old crate of mine (I am talking about full face lift level update) and add the time crate as optional dependency to use its types or at least conversions. Overall I am not in a rush because there is so much work 😅

<b>Naming Inconsistencies</b>

  • The constructor methods essentially convert one ISO date to a Date. That's why Date::from_iso_ywd and Date::yo feel a bit random chosen because there are actual terms defined in the standard. The terms ordinal date or week date seems overall easier to find and search for. Otherwise rustdoc has now this alias feature to make it possible to search for those terms.

    • Date::from_ymd stays the same but I would note in the comment that the ISO calendar date representation is meant.
    • Date::from_iso_ywd -> Date::from_week_date (part of ISO standard anyway so redundant)
    • Date::from_yo -> Date::from_ordinal_date
    • Date::from_julian_day -> Date::from_julian_date (keeping consistenst with the other constructors)
  • The Date type also has methods to convert back into the desired ISO representation. Date::julian_day and Date::iso_year_week are named as getters even though they are not as cheap to access. The as-prefix is also only appropriate for Date::as_yo as it pretty much the underlying data structure and the others are more expensive to compute. into did not make sense because Date is Copy and not being converted to a completely different data type. They are still dates, so I chose the to-prefix.

    • Date::as_ymd -> Date::to_ymd
    • Date::iso_year_week -> Date::to_week_date
    • Date::as_yo -> Date::as_ordinal_date (to-prefix might still be the better choice)
    • Date::julian_day -> Date::to_julian_date
  • I prefer the and-prefix for constructing a new type from an instance because the with-prefix is usually used for constructors.

    • Date::with_hms_* -> Date::and_hms_*
    • Date::with_time -> Date::and_time

<b>API Inconsistencies</b>

  • Date::iso_year_week should return the week day too because every other method that changes the representation returns the same values that is used for the conversion constructor parameters. This way input and output would be the same and it would be easier to learn the API.
  • Why is Date::from_yo_unchecked public and hidden in the docs? Can't it be just pub(crate)?

<b>OffsetDateTime</b>

At first I wanted to suggest to rename it to DateTime but the situation is definitely more complex. I thought at first that the tyoes in this crate are not time zone aware but then OffsetDateTime::now_local wouldn't be fallable. The problem is that the definition of date times as defined in ISO 8601 do not require time zone designators.

date-time = date "T" time [ ("Z" / "UTC") | utc-offset ]

There in fact two types of date times that are still date times at the end of the day. Floating date times are ambigious or relative to the observer. If I said I always want to go jogging at 17 o' clock, it wouldn't matter whether I am in Germany or China. Though for server logs one would prefer to have them in UTC time or at least local time because servers are not necessarily in the same time zone as the developer or customer. The alternative would be an enum but I'm not sure how ergonomic that is and the size would be bigger.

Overall the current API for date times is fine but it lacks documentation. FloatingDateTime wouldn't be so bad but I'm unsure how many people would actually understand it.

<b>Misc</b> Maybe add to the top level documentation that this crate is for working with gregorian dates and that fractal seconds aren't supported.

I hope that this long comment is useful for development!

jhpratt

comment created time in 7 days

push eventtaiki-e/const_fn

Taiki Endo

commit sha 644c56b312aba405de5e2bafefcb52f3f4d3aae4

Update .editorconfig

view details

Taiki Endo

commit sha c04a806f645a72c51d680e1923e8bbc41977745e

Update bors.toml

view details

push time in 8 days

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

I haven't personally been bitten by this yet, but I will have to assume that from the perspective of the OP of this issue you have closed, that removing any attempt to obtain the local offset on *nix, is effectively a removed-feature regression in the 0.2.23 PATCH release. That's my perspective at least.

What are the odds that the OP is actually concurrently mutating the environment in the program in question?

puetzp

comment created time in 8 days

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

Also, regarding the main branch for 0.3.0, would it be reasonable to re-introduce the feature by marking the functions as unsafe and documenting the safety requirements (don't concurrently setenv)?

puetzp

comment created time in 8 days

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

When you backported 01513cbb in f153a1ca5f (diff) and released it as 0.2.23, you "fixed" #293 by essentially disabling the feature of local TZ detection, correct?

I am surprised by this approach. Should any use of getaddrinfo (see rust-lang/rust#27970) also be removed from the rust std library, in your view? IMO, no. Any consumer of libc/musl/* in any language has the same issue. If you ask the libc maintainers to "fix" this, they'll tell you that the safety constraints are well documented in the man pages, and if you mutate the env in a threaded program, you are responsible for the unsafety. Said another way, the workaround for this footgun is "don't do that."

Shouldn't this (#296) be re-opened since removing a feature (per above) isn't PATCH release compatible?

Or shouldn't this be re-opened, re-titled or replaced with a new open issue because you at least want to re-introduce the local TZ feature in a release like 0.3.0?

Then, if a safe (e.g. retaining the "fix" for #293) implementation of local TZ detection is found, would you backport that to a new 0.2.z release, fixing this removed-feature regression?

Assuming the safe implementation is otherwise not risky (likely to introduce other bugs, for example getting the TZ wrong vs localtime_r), this would seem to be the right thing to do. Note, you had a similar regression-fix approach in the v0.2.6 release.

puetzp

comment created time in 8 days

issue commenttime-rs/time

Time 0.2.23 fails to determine local offset

maybe we should provide a feature gate?

puetzp

comment created time in 9 days

issue commenttime-rs/time

The call to `localtime_r` may be unsound

Couldn't we implement localtime_r in Rust, using thread-safe std::env functions? If someone mutates env in another thread using libc that's still a problem of course, but that already is a problem in Rust today and it seems like that's acceptable?

quininer

comment created time in 9 days

issue openedtime-rs/time

Time 0.2.23 fails to determine local offset

Hey there,

after upgrading to v0.2.23 I am unable to retrieve the correct local offset from my system.

println!("{}", UtcOffset::current_local_offset());

returns "+0", while

println!("{}", UtcOffset::try_current_local_offset());

returns a IndeterminateOffsetError.

After downgrading to 0.2.22, both functions correctly return "+1" (CEST).

date '+%z'

also returns "+0100", as expected.

created time in 10 days

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

Fewer issues are of course better but I think the problem I had is not time-specific at all, more of a rust-problem. Cargo should probably suggest running cargo update when a build fails on library-code, dependencies were changed or the local version is out of date. Good night though.

ffactory-ofcl

comment created time in 11 days

issue closedtime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

Hi, I've gone through the cargo.toml of my project to update some dependencies and am now getting the following error:

error[E0624]: associated function `to_mmp` is private
  --> /Users/ffactory/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.2.23/build.rs:30:69
   |
30 |         Some((version, channel, _)) if channel.is_dev() => (version.to_mmp().1 - 2, channel),
   |                                                                     ^^^^^^ private associated function

error[E0624]: associated function `to_mmp` is private
  --> /Users/ffactory/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.2.23/build.rs:31:73
   |
31 |         Some((version, channel, _)) if channel.is_nightly() => (version.to_mmp().1 - 1, channel),
   |                                                                         ^^^^^^ private associated function

error[E0624]: associated function `to_mmp` is private
  --> /Users/ffactory/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.2.23/build.rs:32:49
   |
32 |         Some((version, channel, _)) => (version.to_mmp().1, channel),
   |                                                 ^^^^^^ private associated function

Is that a known bug? I couldn't find anything online, so I'm asking here.

My version: stable-x86_64-apple-darwin - rustc 1.48.0 and MacOS 11.0.1

<details> <summary>This is my Cargo.toml:</summary>

actix-rt = "1.1"
actix = "0.9"
actix-web = {version = "3.2", features = ["rustls"] }
actix-web-actors = "3.0"
actix-files = "0.4"
actix-service = "1.0"
actix-cors = "0.5"
tokio = "0.3"

base64 = "0.13"
async-std = "1.7"
serde = "*"
serde_json = "*"
csv = "1.1"
rustls = "0.19"
env_logger = "0.8"
rand = "0.7"
futures = "0.3"
sha3 = "0.9"

</details>

closed time in 11 days

ffactory-ofcl

issue commenttime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

That worked 🤦‍♂️ god, why didn't I think of that. Thanks so much for the quick help :)

ffactory-ofcl

comment created time in 11 days

issue openedtime-rs/time

Can't compile time v0.2.23 with rust 1.48.0 on MacOS

Hi, I've gone through the cargo.toml of my project to update some dependencies and am now getting the following error:

error[E0624]: associated function `to_mmp` is private
  --> /Users/ffactory/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.2.23/build.rs:30:69
   |
30 |         Some((version, channel, _)) if channel.is_dev() => (version.to_mmp().1 - 2, channel),
   |                                                                     ^^^^^^ private associated function

error[E0624]: associated function `to_mmp` is private
  --> /Users/ffactory/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.2.23/build.rs:31:73
   |
31 |         Some((version, channel, _)) if channel.is_nightly() => (version.to_mmp().1 - 1, channel),
   |                                                                         ^^^^^^ private associated function

error[E0624]: associated function `to_mmp` is private
  --> /Users/ffactory/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.2.23/build.rs:32:49
   |
32 |         Some((version, channel, _)) => (version.to_mmp().1, channel),
   |                                                 ^^^^^^ private associated function

Is that a known bug? I couldn't find anything online, so I'm asking here.

My version: stable-x86_64-apple-darwin - rustc 1.48.0 and MacOS 11.0.1

<details> <summary>This is my Cargo.toml:</summary>

actix-rt = "1.1"
actix = "0.9"
actix-web = {version = "3.2", features = ["rustls"] }
actix-web-actors = "3.0"
actix-files = "0.4"
actix-service = "1.0"
actix-cors = "0.5"
tokio = "0.3"

base64 = "0.13"
async-std = "1.7"
serde = "*"
serde_json = "*"
csv = "1.1"
rustls = "0.19"
env_logger = "0.8"
rand = "0.7"
futures = "0.3"
sha3 = "0.9"

</details>

created time in 11 days

delete branch taiki-e/const_fn

delete branch : extension

delete time in 12 days

PR merged taiki-e/const_fn

Remove extension from $OUT_DIR/version.rs

This file is not a valid rust file by itself. This is usually fine as it is generated to the target directory, but it is not compatible with rough commands like ignore gitignore and search for rust files.

+3 -2

2 comments

2 changed files

taiki-e

pr closed time in 12 days

push eventtaiki-e/const_fn

Taiki Endo

commit sha 3ae46e80ccfd2da9872692cc49d3d69edf337b0e

Remove extension from $OUT_DIR/version.rs This file is not a valid rust file by itself. This is usually fine as it is generated to the target directory, but it is not compatible with rough commands like ignore gitignore and search for rust files.

view details

bors[bot]

commit sha e3b62a81aa70547754b9baf6a75b17041f4fd6c6

Merge #32 32: Remove extension from $OUT_DIR/version.rs r=taiki-e a=taiki-e This file is not a valid rust file by itself. This is usually fine as it is generated to the target directory, but it is not compatible with [rough commands like ignore gitignore and search for rust files](https://github.com/tokio-rs/tokio/blob/tokio-0.3.4/CONTRIBUTING.md#cargo-commands). Co-authored-by: Taiki Endo <te316e89@gmail.com>

view details

push time in 12 days

pull request commenttaiki-e/const_fn

Remove extension from $OUT_DIR/version.rs

Build succeeded:

taiki-e

comment created time in 12 days

more