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

r-spacex/SpaceX-API 6753

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

jhpratt/grid 6

Quick and easy web app to create CSS grid layouts visually

jhpratt/darksky-api 4

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

push eventtime-rs/time

Jacob Pratt

commit sha 2f5503748badc81b52592e693fc9537a79e98088

Broaden formatting requirements Any time can now accept a `Format`, even if the type does not contain sufficient information to successfully return. The internal storage of `Format` has been modified to contain a `&str` rather than a `String`, as ownership of it is never actually required.

view details

Jacob Pratt

commit sha 0287dfa0f8f201eca6c3e0e5bd3539263593eeb3

Increase range of valid dates to ±999,999 years

view details

push time in 13 hours

push eventtime-rs/time

Jacob Pratt

commit sha c01345ff0b9cd541d94ce5e7e15bb6e15d94d608

Broaden formatting requirements Any time can now accept a `Format`, even if the type does not contain sufficient information to successfully return. The internal storage of `Format` has been modified to contain a `&str` rather than a `String`, as ownership of it is never actually required.

view details

push time in 14 hours

push eventtime-rs/time

Jacob Pratt

commit sha 95b0f434ea8960467d44a73541e778eaf9eb34ac

Broaden formatting requirements Any time can now accept a `Format`, even if the type does not contain sufficient information to successfully return. The internal storage of `Format` has been modified to contain a `&str` rather than a `String`, as ownership of it is never actually required.

view details

push time in 14 hours

push eventtime-rs/time

Jacob Pratt

commit sha 66c1f618d2390383b8233de61a709a3764903a8e

Bump MSRV to 1.36.0 I've also noted what the standback prelude is used for, such that it'll be easier to determine when it can be removed in the future.

view details

Jacob Pratt

commit sha db4085b7f0c0b657bce37666f84618cbcef791b6

Remove lazy formatting As an invalid formatting string can be provided, an error would be unidiomatically returned.

view details

Jacob Pratt

commit sha 257574c19bfdf70af3df7d90bc89d2f91e9ef0a2

Revamped macros The macros have been rewritten from scratch. To avoid dealing with proc_macro's limited API, all macros now take a string and parse that. As part of this change, the macros no longer depend on syn, quote, or proc-macro2. A `datetime!` macro was also introduced, equivalent to a date followed immediately by a time.

view details

Jacob Pratt

commit sha 4e7c4c6488f46cb3f9ad0546cff9a124f1fee1b7

Enable formatting of doctests Now that macros only contain a string, there are no issues with formatting them.

view details

Jacob Pratt

commit sha be18e6dbd55bd1a74e4eacdc8c502dd229c89bb2

Un-constify some Duration methods on old compilers

view details

Jacob Pratt

commit sha d5cac773cbb2813c0fb2f2847ca6e98bfcef154b

Add items to CHANGELOG This only includes changes already made, not those planned.

view details

Jacob Pratt

commit sha 3abef5412b6211bc41bd21df1abe572f7964f9c5

Reduce CI time By only running the test suite on `--all-features` and instead checking the powerset, the amount of time taken to run the CI suite should be significantly reduced. Included in this commit is a trivial change to silence a lint on older compilers.

view details

Jacob Pratt

commit sha 02a9d86061a89d784e2d12afa8a960a91b2af49a

Broaden formatting requirements Any time can now accept a `Format`, even if the type does not contain sufficient information to successfully return. The internal storage of `Format` has been modified to contain a `&str` rather than a `String`, as ownership of it is never actually required.

view details

push time in 14 hours

push eventtime-rs/time

Jacob Pratt

commit sha 8dd123a551f451b1558b38a8e5240a896099e329

Reduce CI time By only running the test suite on `--all-features` and instead checking the powerset, the amount of time taken to run the CI suite should be significantly reduced. Included in this commit is a trivial change to silence a lint on older compilers.

view details

push time in 17 hours

push eventtime-rs/time

Jacob Pratt

commit sha b6a12138826d78593bde93bb39861f457257b16d

Reduce CI time By only running the test suite on `--all-features` and instead checking the powerset, the amount of time taken to run the CI suite should be significantly reduced. Included in this commit is a trivial change to silence a lint on older compilers.

view details

push time in 17 hours

push eventtime-rs/time

Jacob Pratt

commit sha e16fca6878d2782d18521444c99092207b4ea37b

Add items to CHANGELOG This only includes changes already made, not those planned.

view details

push time in 17 hours

push eventtime-rs/time

Jacob Pratt

commit sha 3d44913065e59caca1425601763494107f1c2c30

Enable formatting of doctests Now that macros only contain a string, there are no issues with formatting them.

view details

Jacob Pratt

commit sha 04fa0afd87ff89ada044246b493a38cdd807d78b

Un-constify some Duration methods on old compilers

view details

Jacob Pratt

commit sha 95582cbcb3805317f046e2b9102efc08cb275bac

Repository restructuring Make time its own directory, such that the macro code was not contained within it. This has no effect on compilation.

view details

Jacob Pratt

commit sha 4905fa49c8db54ce5ef86d99260f82d454dbade9

Add items to CHANGELOG This only includes changes already made, not those planned.

view details

push time in 17 hours

issue openedRustSec/advisory-db

stdweb is unmaintained/abandoned

See koute/stdweb#403, which has been open just shy of four months.

created time in a day

issue commentRustSec/cargo-audit

stdweb is unmaintained/abandoned

Are you able to move the issue? I don't recall if that feature is still in beta or not.

jhpratt

comment created time in a day

issue commentdandavison/delta

Default dark theme: contrast is too low for comment in addition line

I didn't spend too long playing around with it, but I couldn't find anything that was green yet both distinguishable from the non-emphasized text and had sufficient contrast.

OliverJAsh

comment created time in a day

PR closed time-rs/time

Integer conversion on Solaris and Illumos

The library was not used anywhere and it prevented the build from running on Illumos, this fixes it as far as I can tell.

+1 -0

1 comment

1 changed file

francescocarzaniga

pr closed time in a day

pull request commenttime-rs/time

Integer conversion on Solaris and Illumos

Duplicate of #277, which is awaiting a response from the author.

francescocarzaniga

comment created time in a day

issue commentdandavison/delta

Default dark theme: contrast is too low for comment in addition line

To me, it's not so much the addition line as it is the emphasized part of an addition line. Just about every built-in theme is (nearly) unreadable in that situation. This is with comment lines specifically (Rust if that matters).

OliverJAsh

comment created time in 2 days

starteddandavison/delta

started time in 2 days

push eventtime-rs/time

Jacob Pratt

commit sha 2252bab56c218fae64b37ba59c72ea29122e5e35

Revamped macros The macros have been rewritten from scratch. To avoid dealing with proc_macro's limited API, all macros now take a string and parse that. As part of this change, the macros no longer depend on syn, quote, or proc-macro2. A `datetime!` macro was also introduced, equivalent to a date followed immediately by a time.

view details

push time in 2 days

push eventtime-rs/time

Jacob Pratt

commit sha 8e404e01a435f71099eb6880f64e03a37bd04eff

Revamped macros The macros have been rewritten from scratch. To avoid dealing with proc_macro's limited API, all macros now take a string and parse that. As part of this change, the macros no longer depend on syn, quote, or proc-macro2. A `datetime!` macro was also introduced, equivalent to a date followed immediately by a time.

view details

push time in 2 days

push eventtime-rs/time

Jacob Pratt

commit sha 008507e17700e1545ab57c43b2d114337471e623

Return `Result` from `UtcOffset` constructors

view details

Jacob Pratt

commit sha b92125821e24f99b8004d9934db6c3f3eba17d9d

Bump MSRV to 1.36.0 I've also noted what the standback prelude is used for, such that it'll be easier to determine when it can be removed in the future.

view details

Jacob Pratt

commit sha d82aeefb44dfa49050d324c4a977178639d02c21

Remove lazy formatting As an invalid formatting string can be provided, an error would be unidiomatically returned.

view details

Jacob Pratt

commit sha 521d2207c0c5217c982ebedbc8186501fb52499c

Revamped macros The macros have been rewritten from scratch. To avoid dealing with proc_macro's limited API, all macros now take a string and parse that. As part of this change, the macros no longer depend on syn, quote, or proc-macro2. A `datetime!` macro was also introduced, equivalent to a date followed immediately by a time.

view details

push time in 2 days

issue commentrust-lang/rust

Tracking issue for the `quote!` macro in `proc_macro`

Aside from the issue regarding interpolation noted above, what's holding up stabilization here?

alexcrichton

comment created time in 2 days

create barnchtime-rs/time

branch : v0.3

created branch time in 3 days

delete branch time-rs/time

delete branch : v0.3

delete time in 3 days

issue commentrust-lang/rust

[docs] Attribute to indicate when a function became `const`

While true, I don't personally see a use-case where a function wouldn't exist on older compilers — the crate author is more likely to shim functionality or bump MSRV. But I see your view point.

jhpratt

comment created time in 3 days

issue commentrust-lang/rust

[docs] Attribute to indicate when a function became `const`

My question is specifically relating to const fn, though. If a user sees that a function is const fn, they could naïvely assume that that was always the case, even if it's not. If they're using an older compiler (even with the latest of the library), the function isn't const fn for them. While the docs would render the correct signature if the user builds the docs themself, I'm fairly certain most people, including myself, default to docs.rs.

You could certainly make an argument that I shouldn't be modifying the signature at all, but I feel that progressive enhancement is best while maintaining MSRV. It's just that there's no clear way on how I should be documenting this.

jhpratt

comment created time in 3 days

issue commentrust-lang/rust

[docs] Attribute to indicate when a function became `const`

Having when an item was added would also be quite useful. What I've been doing with the time crate is just saying "this function is const fn when using rustc >= 1.x.0", which obviously isn't ideal. It's a similar use case that led to doc_cfg (albeit that is still unstable).

Has the docs team ever considered exposing something along the lines of #[stable(since=...)] to libraries? Off the top of my head I don't believe you're on that team, but it can't hurt to ask 🙂

jhpratt

comment created time in 3 days

created tagtime-rs/time

tagv0.2.21

Simple time handling in Rust

created time in 3 days

delete tag time-rs/time

delete tag : v0.2.21

delete time in 3 days

created tagtime-rs/time

tagv0.2.21

Simple time handling in Rust

created time in 3 days

push eventtime-rs/time

jhpratt

commit sha 420d3ed5e62b2f8c41e27ff6676b720fcfd27051

Deploying to gh-pages from @ ccd997e947785530fa6410ec5695518c63d82507 🚀

view details

push time in 3 days

push eventtime-rs/time

jhpratt

commit sha 10d82695ce9a10875584f3b0a6331c103fd52d94

Deploying to gh-pages from @ ccd997e947785530fa6410ec5695518c63d82507 🚀

view details

push time in 3 days

push eventtime-rs/time

Jacob Pratt

commit sha fcc5e2ad1deebfe6c651d99732d97993c3027c6f

Display feature required to enable function This was inadvertantly hidden when revamping cfg flags to avoid conflicts.

view details

Jacob Pratt

commit sha ccd997e947785530fa6410ec5695518c63d82507

v0.2.21 release

view details

push time in 3 days

push eventtime-rs/time

jhpratt

commit sha 49a82c81eaea530cd2e1d4676ee79adf32b90edf

Deploying to gh-pages from @ 1cf918ff6848843fba9b7de681facac1c4656196 🚀

view details

push time in 3 days

push eventtime-rs/time

jhpratt

commit sha 60c29a758647a6ea325cc03f3f302cc8184522f7

Deploying to gh-pages from @ 1cf918ff6848843fba9b7de681facac1c4656196 🚀

view details

push time in 3 days

push eventtime-rs/time

Jacob Pratt

commit sha 1cf918ff6848843fba9b7de681facac1c4656196

Make more functions `const fn` Some of these need some small hacks, but it's worth the benefit. Aside from formatting (which requires allocation) and arithmetic (which requires const trait impls), just about everything can now be done at compile time.

view details

push time in 3 days

push eventtime-rs/time

Jacob Pratt

commit sha 950cbaa568f411b00c648a43f8d21b55d99a71d3

Expose implementation details of some error types

view details

Jacob Pratt

commit sha b5399f776e8a538c237e42e1d5b6fbd2ed8cee28

Better documentation of features, improve badges To allow quicker access to the listing of types, enums, etc., put the table of specifiers in a collapsible container element.

view details

Jacob Pratt

commit sha d2da516421c4eea6d93a7855160af8d689e1b53d

Eliminate unnecessary internal macros These two macros were used internally for testing in a couple locations, but are trivially replaced by expanded code.

view details

Jacob Pratt

commit sha 71b7fc1a71009d7851d544fe29bed7cdc04315f5

Make more functions `const fn` Some of these need some small hacks, but it's worth the benefit. Aside from formatting (which requires allocation) and arithmetic (which requires const trait impls), just about everything can now be done at compile time.

view details

push time in 3 days

push eventtime-rs/time

Jacob Pratt

commit sha f18bfd2dcecbb56bfa91591f3f322c536a5b8224

Expose implementation details of some error types

view details

Jacob Pratt

commit sha 13b67621d812cddafa3bfc6b52b812360ced5368

Better documentation of features, improve badges To allow quicker access to the listing of types, enums, etc., put the table of specifiers in a collapsible container element.

view details

Jacob Pratt

commit sha 62dba822242bab6209c0ab285594c19c72991948

Eliminate unnecessary internal macros These two macros were used internally for testing in a couple locations, but are trivially replaced by expanded code.

view details

Jacob Pratt

commit sha 386e929aa4da4781ee46d0f019a3d88363c9a105

Make more functions `const fn` Some of these need some small hacks, but it's worth the benefit. Aside from formatting (which requires allocation) and arithmetic (which requires const trait impls), just about everything can now be done at compile time.

view details

push time in 4 days

issue commentbadges/shields

Customize "red" and "green" color for build status

I was aware of neither RunKit nor the JSON API; I naïvely assumed that I'd have to reimplement the full API myself. I'll give it a shot and see how difficult it is (it's been a while since I've used JavaScript for a server).

It still seems a bit wasteful on the shields.io end, as two requests will be performed instead of one, but that's also not my issue 🙂

jhpratt

comment created time in 4 days

issue commentbadges/shields

Customize "red" and "green" color for build status

Yes, they are shields.io badges with custom colors.

If the goal is standardization, why support custom colors at all? Having to implement (and host!) an endpoint seems like quite an extreme measure just to change a color.

jhpratt

comment created time in 4 days

issue openedbadges/shields

Customize "red" and "green" color for build status

Semi-related: #4396

Would it be possible to set a custom color for "red" and "green" for the build status? I have a certain preference for pastel/muted colors, and the current colors "pop" a bit much for my liking. It is also inconsistent with the other badges I have adjacent to the build status.

created time in 5 days

issue openedrust-lang/rust

[docs] Attribute to indicate when a function became `const`

Having an attribute like #[doc(const_since("Rust 1.45"))] could be quite useful. It could be similar in appearance to #[doc(cfg(...))], and would likely be similar to implement.

I believe the best design for an API like this would be accepting a string, such that the author could clarify whether it's Rust's version that matters or the crate's version (obviously for stdlib this doesn't matter).

created time in 6 days

push eventtime-rs/time

jhpratt

commit sha 79c0dfae910e32573e1d445ea6d5ef981f6101bf

Deploying to gh-pages from @ 2a53bdd9f2d2f03cce5b67b237257641dfcef542 🚀

view details

push time in 6 days

push eventtime-rs/time

jhpratt

commit sha 9dd8dc059ca9e1911633604a52ef18e0a60ebcf6

Deploying to gh-pages from @ 2a53bdd9f2d2f03cce5b67b237257641dfcef542 🚀

view details

push time in 6 days

push eventtime-rs/time

Jacob Pratt

commit sha 2a53bdd9f2d2f03cce5b67b237257641dfcef542

Improve test coverage Cover errors and serde. Rand coverage was improved with a new seed, and Date now has its debug implementation checked. As part of this coverage expansion, it was discovered that only one implementation of a generic function was being used internally. This generic type was removed in favor of concrete types, which slightly reduces the amount of code present.

view details

push time in 6 days

push eventtime-rs/time

Jacob Pratt

commit sha 02f7ca96a231b6bbaa420a343486c578aee8d28a

Improve test coverage Cover errors and serde. Rand coverage was improved with a new seed, and Date now has its debug implementation checked. As part of this coverage expansion, it was discovered that only one implementation of a generic function was being used internally. This generic type was removed in favor of concrete types, which slightly reduces the amount of code present.

view details

push time in 6 days

issue commentxd009642/tarpaulin

Help: call for testing projects

The time crate (time-rs/time) has decent coverage (~95% on the main crate), and is roughly 5k lines of source code. Its dependencies are minimal ("standard" proc macro dependencies, a couple of macros for progressive enhancement, and system APIs). It definitely works on x86!

From manually looking at the coverage, it looks like there's a fair number of false negatives.

xd009642

comment created time in 6 days

push eventtime-rs/time

Jacob Pratt

commit sha 430f8293b685334d0e3516c4998ef7ff9b8e7c8b

Improve test coverage Cover errors and serde. Rand coverage was improved with a new seed, and Date now has its debug implementation checked. As part of this coverage expansion, it was discovered that only one implementation of a generic function was being used internally. This generic type was removed in favor of concrete types, which slightly reduces the amount of code present.

view details

push time in 6 days

issue commentxd009642/tarpaulin

Misses in coverage

Looks like one of the largest instances of false negatives in the code for time is a parameter or the initialization of a struct (when a variable with that name already exists, typically). Other situations that sometimes aren't covered is when an exprssion is split over multiple lines.

impl Distribution<Duration> for Standard {
    fn sample<R: Rng + ?Sized>(&self, rng: &mut R) -> Duration {
        let seconds = Standard.sample(rng);
        Duration::new(
            seconds, // This line alone isn't covered.
            seconds.signum() as i32 * rng.gen_range(0, 1_000_000_000),
        )
    }
}
pub const fn try_from_hms(
    hour: u8,
    minute: u8,
    second: u8,
) -> Result<Self, error::ComponentRange> {
    ensure_value_in_range!(hour in 0 => 23);
    ensure_value_in_range!(minute in 0 => 59);
    ensure_value_in_range!(second in 0 => 59);
    Ok(Self {
        hour, // this
        minute, // this
        second, // and this line are not covered
        nanosecond: 0,
    })
}
pub(crate) fn from_iso_ywd_unchecked(year: i32, week: u8, weekday: Weekday) -> crate::Date {
    let ordinal = week as u16 * 7 + weekday.iso_weekday_number() as u16
        - (Self::from_yo_unchecked(year, 4)
            .weekday() // this
            .iso_weekday_number() as u16 // this
            + 3); // and this line are uncovered, despite the first chunk of the expression being covered

    if ordinal < 1 {
        return Self::from_yo_unchecked(year - 1, ordinal + days_in_year(year - 1));
    }

    let days_in_cur_year = days_in_year(year);
    if ordinal > days_in_cur_year {
        Self::from_yo_unchecked(year + 1, ordinal - days_in_cur_year)
    } else {
        Self::from_yo_unchecked(year, ordinal)
    }
}

Having no idea how tarpaulin actually works aside from it putting "markers" to detect when certain code is run, I think marking an entire expression as covered is what would be necessary. The struct initialization is almost certainly optimized out, even in debug mode (especially in the example provided), so any marker would be futile.

xd009642

comment created time in 7 days

created tagtime-rs/time

tagv0.2.20

Simple time handling in Rust

created time in 7 days

push eventtime-rs/time

jhpratt

commit sha df11d46f8ce039ff31608e3365587c26b3099fdc

Deploying to gh-pages from @ f751f8faa5bfc829238fe487aa5bdf28eb524c5f 🚀

view details

push time in 7 days

push eventtime-rs/time

jhpratt

commit sha 9f59e57b534b300f8d2557c422046ea22129b7df

Deploying to gh-pages from @ f751f8faa5bfc829238fe487aa5bdf28eb524c5f 🚀

view details

push time in 7 days

push eventtime-rs/time

Jacob Pratt

commit sha df29bd10d0f574778ab52f66518b1d4c9e1aa2cb

Improve tests - Split util functions into separate module - `HashSet` instead of slice when checking the number of weeks in a year - Eliminate unnecessary `Result`s - Shorten duration to sleep for when testing `Instant` While shortening the duration the thread sleeps for seems minimal, it results in a reduction of 1.485 seconds per test run. As CI executes the feature powerset, this results in a direct reduction of 23+ seconds per target.

view details

Jacob Pratt

commit sha f751f8faa5bfc829238fe487aa5bdf28eb524c5f

Correct Julian day implementation Fixes #276. As this is a far-reaching bug fix, this will be released without waiting for any other changes that may come.

view details

push time in 7 days

issue closedtime-rs/time

Round-trip Julain day does not always result in the original value

While an issue like this may seem localized at first, arithmetic with Dates is implemented in terms of the Julian day for ease of implementation. Given that arithmetic is quite widespread, this has implications as far as deserializing an OffsetDateTime; this discovery actually occurred during the expansion of test coverage.

This code snippet, while not verbatim from the repository, is functionally equivalent to what actually occurs.

const Y: i64 = 4716;
const J: i64 = 1401;
const M: i64 = 2;
const N: i64 = 12;
const R: i64 = 4;
const P: i64 = 1461;
const Q: i64 = 0;
const V: i64 = 3;
const U: i64 = 5;
const S: i64 = 153;
const T: i64 = 2;
const W: i64 = 2;
const A: i64 = 184;
const B: i64 = 274277;
const C: i64 = -38;

#[derive(Debug, Clone, Copy)]
struct Date {
    year: i64,
    month: i64,
    day: i64,
}

impl Date {
    fn julian_day(self) -> i64 {
        let Self { year, month, day } = self;

        let h = month - M;
        let g = year + Y - (N - h) / N;
        let f = (h - 1 + N).rem_euclid(N);
        let e = (P * g + Q) / R + day - 1 - J;
        let j = e + (S * f + T) / U;
        j - (3 * ((g + A) / 100)) / 4 - C
    }

    fn from_julian_day(julian_day: i64) -> Self {
        let f = julian_day + J;
        let f = f + (((4 * julian_day + B) / 146_097) * 3) / 4 + C;
        let e = R * f + V;
        let g = e.rem_euclid(P) / R;
        let h = U * g + W;
        let day = h.rem_euclid(S) / U + 1;
        let month = (h / S + M).rem_euclid(N) + 1;
        let year = e / P - Y + (N + M - month) / N;
        Self { year, month, day }
    }
}

fn main() {
    let date = Date {
        year: -100_000,
        month: 1,
        day: 1,
    };
    println!("Before round-trip: {:?}", date);
    println!("Julian day: {}", date.julian_day());
    println!("After round-trip: {:?}", Date::from_julian_day(date.julian_day()));
}

(Playground)

I obtained this algorithm from the United States Naval Observatory. The document can be viewed here (archive.org, as the original site is currently down). §15.11, which starts on page 33, is where the relevant information is at.

As this doesn't appear to affect dates near current, this hopefully doesn't affect any real-world code. I intend on determining where the conversion begins to diverge, potentially allowing for manual correction of incorrect values. This shouldn't be too difficult, as there's only ~73 million days in the range of ±100,000 years.


Pinging @pfmooney & @jclulow to see if you have any ideas. I'm not aware of any other ways to calculate the Julian day or convert back to a Gregorian date.

closed time in 7 days

jhpratt

pull request commenttime-rs/time

fixed solaris build

Two relatively minor things:

  • Would you mind adding Solaris to CI? It should amount to a single line addition if the target has been around long enough.
  • If the Solaris target has been around since before TryFrom was stabilized, the import should be use standback::convert::TryFrom. This allows usage on older compilers, while maintaining forward compatibility.
AviKozokin

comment created time in 8 days

issue commenttime-rs/time

Round-trip Julain day does not always result in the original value

I have found a different algorithm for the bidirectional conversion to & from the Julian day. A full description of the algorithm from Peter Baum is available here.

I can confirm that this algorithm works with floating point numbers for all dates between ±999,999 years — all 730,484,634 were verified. Now it's just a matter of getting this to work with integers, even if it uses floating point arithmetic internally.

jhpratt

comment created time in 8 days

issue commenttime-rs/time

Round-trip Julain day does not always result in the original value

As I suspected, it's the Date::from_julian_day method that is faulty. It is currently capable of producing an invalid value, in that -100000-02-28 turns into -99999-02-29, despite the fact that the latter is not a leap year.

jhpratt

comment created time in 9 days

issue openedtime-rs/time

Round-trip Julain day does not always result in the original value

While an issue like this may seem localized at first, arithmetic with Dates is implemented in terms of the Julian day for ease of implementation. Given that arithmetic is quite widespread, this has implications as far as deserializing an OffsetDateTime; this discovery actually occurred during the expansion of test coverage.

This code snippet, while not verbatim from the repository, is functionally equivalent to what actually occurs.

const Y: i64 = 4716;
const J: i64 = 1401;
const M: i64 = 2;
const N: i64 = 12;
const R: i64 = 4;
const P: i64 = 1461;
const Q: i64 = 0;
const V: i64 = 3;
const U: i64 = 5;
const S: i64 = 153;
const T: i64 = 2;
const W: i64 = 2;
const A: i64 = 184;
const B: i64 = 274277;
const C: i64 = -38;

#[derive(Debug, Clone, Copy)]
struct Date {
    year: i64,
    month: i64,
    day: i64,
}

impl Date {
    fn julian_day(self) -> i64 {
        let Self { year, month, day } = self;

        let h = month - M;
        let g = year + Y - (N - h) / N;
        let f = (h - 1 + N).rem_euclid(N);
        let e = (P * g + Q) / R + day - 1 - J;
        let j = e + (S * f + T) / U;
        j - (3 * ((g + A) / 100)) / 4 - C
    }

    fn from_julian_day(julian_day: i64) -> Self {
        let f = julian_day + J;
        let f = f + (((4 * julian_day + B) / 146_097) * 3) / 4 + C;
        let e = R * f + V;
        let g = e.rem_euclid(P) / R;
        let h = U * g + W;
        let day = h.rem_euclid(S) / U + 1;
        let month = (h / S + M).rem_euclid(N) + 1;
        let year = e / P - Y + (N + M - month) / N;
        Self { year, month, day }
    }
}

fn main() {
    let date = Date {
        year: -100_000,
        month: 1,
        day: 1,
    };
    println!("Before round-trip: {:?}", date);
    println!("Julian day: {}", date.julian_day());
    println!("After round-trip: {:?}", Date::from_julian_day(date.julian_day()));
}

(Playground)

I obtained this algorithm from the United States Naval Observatory. The document can be viewed here (archive.org, as the original site is currently down). §15.11, which starts on page 33, is where the relevant information is at.

As this doesn't appear to affect dates near current, this hopefully doesn't affect any real-world code. I intend on determining where the conversion begins to diverge, potentially allowing for manual correction of incorrect values. This shouldn't be too difficult, as there's only ~73 million days in the range of ±100,000 years.


Pinging @pfmooney & @jclulow to see if you have any ideas. I'm not aware of any other ways to calculate the Julian day or convert back to a Gregorian date.

created time in 9 days

issue commentrust-random/rand

Support mocking of Rng:: gen_range

With my understanding of the way the traits interact, I don't believe it would be possible to override the behavior for this struct specifically, at least until specialization lands on stable, correct?

For my testing purposes (presumably others' as well), bias is fine. That's kind of the point of mocking, after all! Admittedly, I'm not sure how the behavior could change, but I (obviously) wish it were different.

gruszczy

comment created time in 10 days

issue commentrust-random/rand

Support mocking of Rng:: gen_range

For what it's worth I was quite surprised when I discovered that gen_range didn't work as expected. Given that I'm mocking a RNG, I would've expected the number to increment in a wrapping manner, as is documented. I shouldn't need to pull in a proper RNG (even if it is seeded) just to ensure all behavior is covered.

Basically, I'd expect the following to print [0, 1, 2, 3, 4, 5, 6, 0]

use rand::rngs::mock::StepRng;
use rand::Rng;

fn main() {
    let mut rng = StepRng::new(0, 1);
    let mut sample = vec![];
    for _ in 0..8 {
        sample.push(rng.gen_range(0, 7));
    }
    println!("{:?}", sample);
}

The failure of the current behavior is surprising at beset.

gruszczy

comment created time in 10 days

push eventtime-rs/time

jhpratt

commit sha 7abb3807cbc61b91cad2b890878f70420c0ef667

Deploying to gh-pages from @ 2632eacf725a12f1990a0fb54db4a7317ce1a5e1 🚀

view details

push time in 11 days

push eventtime-rs/time

jhpratt

commit sha ecd6e789b1d072d52af149fec0f8c9823f53d730

Deploying to gh-pages from @ 2632eacf725a12f1990a0fb54db4a7317ce1a5e1 🚀

view details

push time in 11 days

push eventtime-rs/time

Jacob Pratt

commit sha 44eda4003d0fbcfce9c68ffee3e5d8bb6abf2872

Docs on construction from timestamp and nanos Resolves #260.

view details

Jacob Pratt

commit sha 2632eacf725a12f1990a0fb54db4a7317ce1a5e1

Unix timestamp in nanoseconds <=> OffsetDateTime Resolves #259.

view details

push time in 11 days

issue closedtime-rs/time

[Feature] Convert between OffsetDateTime and i64 where the i64 is nanoseconds since the UNIX epoch

I have several projects in a space where I need nanosecond precision timestamps. I store these in PostgreSQL as INT8 (i64) which gives ~500 -ish years which is more than enough for my domain.

Chrono has an interesting anecdote on this:

https://docs.rs/chrono/0.4.11/chrono/struct.DateTime.html#method.timestamp_nanos

Note that this does reduce the number of years that can be represented from ~584 Billion to ~584. (If this is a problem, please file an issue to let me know what domain needs nanosecond precision over millennia, I'm curious.)

Proposal

// UNIX nanoseconds -> OffsetDateTime
OffsetDateTime::from_unix_timestamp_nanos(nanos)

Similar to https://docs.rs/time/0.2.16/time/struct.OffsetDateTime.html#method.from_unix_timestamp

// OffsetDateTime -> UNIX nanoseconds
dt.timestamp_nanos()

Similar to https://docs.rs/time/0.2.16/time/struct.OffsetDateTime.html#method.timestamp

Side note, should this method be called .unix_timestamp_nanos() ? It feels inconsistent with the from_ version.

closed time in 11 days

mehcode

issue closedtime-rs/time

[Feature] Construct an OffsetDateTime from a normal UNIX timestamp (in seconds) and the fractional nanoseconds

Equivalent method in chrono:

https://docs.rs/chrono/0.4.11/chrono/naive/struct.NaiveDateTime.html#method.from_timestamp

As we already have a .from_unix_timestamp that only takes seconds, could/should we make a breaking change in v0.3 or perhaps another method?


Related to #259 and my need to deal in nanosecond timestamps but sometimes I have the 12-byte pair.

closed time in 11 days

mehcode

issue commenttime-rs/time

Time v0.3 tracking issue

Given the significant number of changes I've made on the main branch since originally creating the v0.3 branch, I'll almost certainly re-branch and cherrypick certain changes.

I've also re-implemented the various macros such that they have no dependencies. The macros will accept strings that are otherwise fully compatible with 0.2. This both makes parsing simpler and prevents rustfmt from making stupid decisions.

jhpratt

comment created time in 11 days

issue commenttime-rs/time

[Feature] Convert between OffsetDateTime and i64 where the i64 is nanoseconds since the UNIX epoch

Finally getting around to doing this. You're absolutely right that the method should be called .unix_timestamp_nanos() and .unix_timestamp() for consistency. I'll make this change in 0.3.

mehcode

comment created time in 11 days

push eventtime-rs/time

jhpratt

commit sha 6b153f8fe7a349bb107ea62bcd6b3f1bf7eae99e

Deploying to gh-pages from @ cf2918fd2286c5aacb88666c0f323dd7f87b7a25 🚀

view details

push time in 11 days

push eventtime-rs/time

jhpratt

commit sha 72108b642dea37bfff33067bb676eb2d5a17488c

Deploying to gh-pages from @ cf2918fd2286c5aacb88666c0f323dd7f87b7a25 🚀

view details

push time in 11 days

push eventtime-rs/time

Jacob Pratt

commit sha cf2918fd2286c5aacb88666c0f323dd7f87b7a25

Reduce uploaded crate size by 37% By splitting nearly every test into a separate tests directory, they can be omitted from the crates.io upload. As a bonus, it helps ensure that any changes to APIs are wholly internal. This would have caught a couple errors in the past. As part of this change, I've also run `cargo diet`, which excludes any file (in this case including the tests directory) that isn't needed on crates.io. This eliminates things like rustfmt, the logo, and CI config.

view details

push time in 11 days

delete tag time-rs/time

delete tag : foo

delete time in 11 days

push eventtime-rs/time

Jacob Pratt

commit sha 571e39718b383b9db18623192d0a894c37eb6141

Reduce uploaded crate size by 37% By splitting nearly every test into a separate tests directory, they can be omitted from the crates.io upload. As a bonus, it helps ensure that any changes to APIs are wholly internal. This would have caught a couple errors in the past. As part of this change, I've also run `cargo diet`, which excludes any file (in this case including the tests directory) that isn't needed on crates.io. This eliminates things like rustfmt, the logo, and CI config.

view details

push time in 11 days

created tagtime-rs/time

tagfoo

Simple time handling in Rust

created time in 11 days

push eventtime-rs/time

Jacob Pratt

commit sha d0258718b218dae2eeb36cc4f42da56562fd295f

Reduce uploaded crate size by 37% By splitting nearly every test into a separate tests directory, they can be omitted from the crates.io upload. As a bonus, it helps ensure that any changes to APIs are wholly internal. This would have caught a couple errors in the past. As part of this change, I've also run `cargo diet`, which excludes any file (in this case including the tests directory) that isn't needed on crates.io. This eliminates things like rustfmt, the logo, and CI config.

view details

push time in 11 days

issue closedtime-rs/time

Reverse dependency upgrades to 0.2

This is a tracking issue for the effort to upgrade a number of reverse dependencies to time 0.2. If you're a maintainer or contributor to a crate and looking to upgrade from time 0.1 to 0.2, leave any questions you may have below! I'll do my best to address your questions & concerns.

Crates that have already updated:

Crates with open PRs:

  • hyper [ref]
  • bson-rust [ref] — removal

Other crates that could be updated:

  • reqwest (blocked by hyper)
  • rustc-test — may not need the time crate at all
  • rusqlite
  • instant
  • diesel
  • nickel
  • pbr
  • rouille

closed time in 11 days

jhpratt

push eventtime-rs/time

jhpratt

commit sha 08999aa8beab1ddb50fc1d50caeed6e5144d94ad

Deploying to gh-pages from @ 302c928eeb1c74e50df3ebf3e0331af52f8ebef8 🚀

view details

push time in 12 days

push eventtime-rs/time

jhpratt

commit sha 0cd7af2999a27ec1431c63e2291bf5e7cfcac841

Deploying to gh-pages from @ 302c928eeb1c74e50df3ebf3e0331af52f8ebef8 🚀

view details

push time in 12 days

issue openedmicrosoft/vscode

Creating a git tag with no message should not set a message

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ --> <!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ --> <!-- Please search existing issues to avoid creating duplicates. -->

When creating a git tag via the <kbd>F1</kbd> menu, the user is prompted to enter a tag name — this is of course mandatory. After that is entered, the user is prompted to enter a tag message. If this is left blank (the user just presses <kbd>Enter</kbd>), the tag name is set as the tag message. This is neither the behavior that I expect not the behavior I desire. I would expect either an annotated tag to be created with an empty message or a lightweight tag, the latter being preferred.

<sup>(not sure whether to put this as a bug or feature request)</sup>

created time in 12 days

push eventtime-rs/time

Jacob Pratt

commit sha 302c928eeb1c74e50df3ebf3e0331af52f8ebef8

0.2.19 release

view details

push time in 12 days

created tagtime-rs/time

tagv0.2.19

Simple time handling in Rust

created time in 12 days

push eventtime-rs/time

jhpratt

commit sha ab828a64ff9c4834b0dd3c0fb44aa660575d20e2

Deploying to gh-pages from @ da8ad67120d29a3ed21b33974bdd3c5d37951d1e 🚀

view details

push time in 12 days

push eventtime-rs/time

jhpratt

commit sha 58de701147f5aea3bf08b396a2dca30c48d835a1

Deploying to gh-pages from @ da8ad67120d29a3ed21b33974bdd3c5d37951d1e 🚀

view details

push time in 12 days

push eventtime-rs/time

Jacob Pratt

commit sha 42250fbd9375a4e4fb3f0196c8c75a1595180357

Avoid panicking on invalid formatting string An additional error type has been created indicating the type does not have sufficient information to be able to format/parse

view details

Jacob Pratt

commit sha 28094d61fda9393b9b65c9d23ea1fc7466de6076

Declare build script dependency on env variable Resolves #275.

view details

Jacob Pratt

commit sha da8ad67120d29a3ed21b33974bdd3c5d37951d1e

Improve test coverage Coverage of the time crate itself now sits at roughly 88%. Serde formats and error.rs have not been explicitly tested. Serde formats will change in 0.3, and are currently simple implementations. Error structs are also largely trivial.

view details

push time in 12 days

issue closedtime-rs/time

build script does not declare dependency on COMPILING_UNDER_CARGO_WEB

> COMPILING_UNDER_CARGO_WEB=1 cargo build --target wasm32-unknown-unknown
[...]
error[E0433]: failed to resolve: use of undeclared type or module `wasm_bindgen`
[...]

> cargo build --target wasm32-unknown-unknown
[...]
error[E0433]: failed to resolve: use of undeclared type or module `wasm_bindgen`
[...]

> cargo clean

> cargo build --target wasm32-unknown-unknown
[...]
    Finished dev [unoptimized + debuginfo] target(s) in 41.81s

Build scripts must use cargo:rerun-if-env-changed to declare the environment variables they depend on, otherwise Cargo will use the previously cached run.

From discussion on the community discord https://discord.com/channels/273534239310479360/274215136414400513/753183573145681940

closed time in 12 days

Nemo157

PR opened actions-rs/tool-cache

Add cargo-hack

Resolves #14

+1 -0

0 comment

1 changed file

pr created time in 13 days

push eventjhpratt/tool-cache

Jacob Pratt

commit sha f2260fab86604acbe8108874b37b32cb701ab37b

Add cargo-hack Resolves #14

view details

push time in 13 days

fork jhpratt/tool-cache

💾 Binary crates cache for @actions-rs/install Action

fork in 13 days

issue commenttime-rs/time

build script does not declare dependency on COMPILING_UNDER_CARGO_WEB

Ok, thanks. I'll get a release out later today or tomorrow, as I uncovered a couple other bugs while expanding test coverage.

Nemo157

comment created time in 13 days

issue commenttime-rs/time

build script does not declare dependency on COMPILING_UNDER_CARGO_WEB

Ah, my bad. I was under the interpretation that the build script was always run unless there was a "rerun-if" emitted, in which case it would trigger only when necessary.

What's the proper thing to do here? Would pushing a release with an updated build script suffice, or does the change have to be reverted? I'd like to avoid reverting if possible, since the intent behind the switch to begin with was to avoid cfg conflicts with other crates.

Nemo157

comment created time in 13 days

issue commentnvzqz/static-assertions-rs

Feature suggestion: testability

Isn't this just assert!()?

Amomum

comment created time in 14 days

push eventjhpratt/single-crate-proc-macro-rfc

Jacob Pratt

commit sha 49db59dc60b923d4f1290fe3734a117439ae3fa6

Begin single_crate_proc_macro RFC

view details

push time in 14 days

fork jhpratt/rfcs

RFCs for changes to Rust

https://rust-lang.github.io/rfcs/

fork in 14 days

push eventtime-rs/time

Jacob Pratt

commit sha d0cc8d24ccfaf6f3e19b813bb5d7a78037dc4d4e

Remove link to Matrix room GitHub Discussions (https://github.com/time-rs/time/discussions) should be used where Matrix would have otherwise been used.

view details

push time in 15 days

issue commentxd009642/tarpaulin

Fails to compile time crate

FYI to avoid more changes than necessary when switching from 0.2 to 0.3, I've recently backported a large number of commits from the 0.3 branch. You should be able to use tarpaulin with 0.2 as of last week. As I also removed the #[inline] attributes, I can now get reasonably accurate coverage (just a few false negatives).

jhutchins

comment created time in 16 days

issue commentrust-dev-tools/rust-semverver

Build fails with recent nightly

What is a nightly that is known to work?

jrobsonchase

comment created time in 16 days

push eventtime-rs/time

jhpratt

commit sha 844e9874abff4892630e53d91499a229c41b8612

Deploying to gh-pages from @ fc8a418fb3caa19f631c28bc4145092c235d31d5 🚀

view details

push time in 16 days

push eventtime-rs/time

jhpratt

commit sha 7e6666ddd60cbff8b25c89a47cd2ab018ace5de0

Deploying to gh-pages from @ fc8a418fb3caa19f631c28bc4145092c235d31d5 🚀

view details

push time in 16 days

push eventtime-rs/time

Jacob Pratt

commit sha fc8a418fb3caa19f631c28bc4145092c235d31d5

Remove unused import

view details

push time in 16 days

push eventtime-rs/time

jhpratt

commit sha 42171154e8a7287cac69e49245f0adabcff638e7

Deploying to gh-pages from @ 5a9ea256d32e97452a42f061d6df8009805ad24c 🚀

view details

push time in 16 days

push eventtime-rs/time

jhpratt

commit sha 5ed32b70bd375da62649996da08e1ffc57fb489c

Deploying to gh-pages from @ 5a9ea256d32e97452a42f061d6df8009805ad24c 🚀

view details

push time in 16 days

created tagtime-rs/time

tagv0.2.18

Simple time handling in Rust

created time in 16 days

push eventtime-rs/time

Jacob Pratt

commit sha b089ceae0552e9cf5fe54d499c7ce1b32ed89ab3

constify more methods At the expense of slightly worse error messages, a few constructors of `Date` and `Time` can be made `const fn` from Rust 1.46 onwards.

view details

Jacob Pratt

commit sha 6f12e5d746135a1b3cf9b61a6c2c810ecea4ff8e

Fix intra-doc links

view details

Jacob Pratt

commit sha e0e3886602d715d1119592d4855684c4b17f172b

0.2.18 release

view details

Jacob Pratt

commit sha f5f0fe7cdde1e9851ad92c6b24645f27810264af

Limit documentation branch to single commit There's no reason to maintain a commit history, as the documentation can be generated from the associated commit on the main branch.

view details

Jacob Pratt

commit sha 5a9ea256d32e97452a42f061d6df8009805ad24c

Improved cache As the Cargo.lock file doesn't get checked into the repository, Cargo.toml is the next best thing.

view details

push time in 16 days

push eventtime-rs/time

twistedfall

commit sha 9dc99dc7f10650c3e7ba1ae395fa43a01d66379c

Fix incorrect parsing of the offset of a RFC-3339 time string (#274) The offset in 2020-09-08T08:44:31+02:30 was incorrectly interpreted as 2 minutes and 30 seconds.

view details

push time in 16 days

more