Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose Time::MIN and Time::MAX #686

Closed
wants to merge 1 commit into from
Closed

Expose Time::MIN and Time::MAX #686

wants to merge 1 commit into from

Conversation

jrandolf
Copy link

@jrandolf jrandolf commented Jun 8, 2024

This PR exposes the internal max/min values for Time. These are useful for building ranges.

Copy link

codecov bot commented Jun 8, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.7%. Comparing base (4a74924) to head (956d90d).
Report is 44 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##            main    #686     +/-   ##
=======================================
- Coverage   97.8%   97.7%   -0.1%     
=======================================
  Files         81      83      +2     
  Lines       9378    9000    -378     
=======================================
- Hits        9169    8793    -376     
+ Misses       209     207      -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@jhpratt
Copy link
Member

jhpratt commented Jun 8, 2024

Can you elaborate on your use case? Even within this repository the values are used in very few locations, all of which could easily be replaced without issue.

@jhpratt jhpratt added C-feature-request Category: a new feature (not already implemented) A-core Area: anything not otherwise covered labels Jun 8, 2024
@jrandolf
Copy link
Author

jrandolf commented Jun 8, 2024

Can you elaborate on your use case? Even within this repository the values are used in very few locations, all of which could easily be replaced without issue.

We have a scheduling app that accepts missing start and end times. To make computations easier, we replace these bounds with actual values, specifically Time::MIN and Time::MAX.

@jhpratt
Copy link
Member

jhpratt commented Jun 9, 2024

In that case, why wouldn't you want to be explicit about the exact value being added?

@jrandolf
Copy link
Author

jrandolf commented Jun 9, 2024

In that case, why wouldn't you want to be explicit about the exact value being added?

We are being explicit. By not specifying the range ends, you opt in to MIN as the minimum and MAX as the maximum. We could enforce using MIN instead of a missing lower bound, but for the upper bound, the problem is slightly more difficult as specifying an upper bound is dependent on the precision.

That said, we were able to workaround MIN/MAX by subtracting 1.nanosecond() from MIDNIGHT. If you're not convinced of this PR, maybe we can add some documentation about max bounds and how to achieve them (perhaps using the workaround just mentioned).

@jrandolf
Copy link
Author

@jhpratt Gentle ping, could you please take a look? If you feel this PR isn't useful, please close.

@jhpratt
Copy link
Member

jhpratt commented Jun 18, 2024

I've decided that this would cause minimal confusion given that Ord is already implemented. However, MIDNIGHT already exists with identical semantics as MIN, so I'd like to avoid exposing that (I'll probably look into removing it). I would accept an update that makes MAX and only MAX public. You can put #[doc(alias = "MIN")] on MIDNIGHT if you'd like as well.

@jrandolf jrandolf closed this by deleting the head repository Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-core Area: anything not otherwise covered C-feature-request Category: a new feature (not already implemented)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants