-
Notifications
You must be signed in to change notification settings - Fork 155
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
Eliminate OffsetDateTime & ZonedDateTime #158
Comments
I don't think we have much to add beyond what @devjgm said in #139. One thing I can say is that I don't believe we have ever had a request to add a type beyond our absolute-time, absolute-duration, and time-zone ones ( People may have created their own hybrids, I guess, but they have never risen to the level of noticeability. |
FWIW, I think this is a good idea. I maintain rSchedule, a typescript recurring events library. Through some trial and error, I arrived at a similar abstraction for implementing the recurrence logic. When a user provides a date, it is converted into a custom absolute time object (which mostly relies on the standard The rrulejs recurrence library uses a similar (albeit, more crudely implemented) strategy where the user is required to convert provided dates into an absolute time format (basically, the user needs to handle the conversion rather than the library doing it for them -- but the idea is the same).
^ Agreed. This format is much easier to reason over while also avoiding timezone issues. This decision also leaves open the possibility of adding a |
Just fyi this is what I'm presenting as an update at TC39 |
@pipobscure maybe this should be a separate issue, but one area that is unclear when looking at the code for the current polyfill (which has eliminated ZonedDateTime & OffsetDateTime), is what happens when the user attempts to combine a zoneless
|
Depends on how you do it. TZ.getAbsoluteFor(DT) => [] for the case a datetime exists twice (DST) TZ.getAbsoluteFor(DT) => [earlier, later] |
For what it's worth, the Abseil (C++, no exceptions) absl::CivilSecond +
absl::TimeZone function returns three absl::Time values:
struct TimeInfo {
enum CivilKind {
UNIQUE, // the civil time was singular (pre == trans == post)
SKIPPED, // the civil time did not exist (pre >= trans > post)
REPEATED, // the civil time was ambiguous (pre < trans <= post)
} kind;
Time pre; // time calculated using the pre-transition offset
Time trans; // when the civil-time discontinuity occurred
Time post; // time calculated using the post-transition offset
};
Abseil also has a helper function that returns a single, "order preserving"
absl::Time value, which we believe is what most simple applications want:
// FromCivil()
//
// Helper for TimeZone::At(CivilSecond) that provides "order-preserving
// semantics." If the civil time maps to a unique time, that time is
// returned. If the civil time is repeated in the given time zone, the
// time using the pre-transition offset is returned. Otherwise, the
// civil time is skipped in the given time zone, and the transition time
// is returned. This means that for any two civil times, ct1 and ct2,
// (ct1 < ct2) => (FromCivil(ct1) <= FromCivil(ct2)), the equal case
// being when two non-existent civil times map to the same transition
time.
inline Time FromCivil(CivilSecond ct, TimeZone tz) {
const auto ti = tz.At(ct);
if (ti.kind == TimeZone::TimeInfo::SKIPPED) return ti.trans;
return ti.pre;
}
… |
Thanks! That sounds very much like what we’re doing adjusted for different idioms. Working with a state flag like that sounds just right for C/C++ but would be weird in JS. But being able to get 0, 1 or 2 results sounds right and exactly like what we’re thinking for TZ. getAbsoluteFor(DT) For the DT.withZone(TZ) where a single result is expected, throwing seems idiomatic for JS. |
I'm in two minds about this. On one hand, there was a large discussion in #84 about how useful the concept of What I'm most concerned about here, though, is the process by which it was dropped. The removal of 2 API objects was proposed with just a single "pro" and no "cons" as justification, which seems pretty weak from where I sit. Then the burden of proof for keeping them was put on to everyone else. That's the inverse of how it should go. Unfortunately, many of the large API changes are being done with an almost complete absence of practical examples (something I raised in #26 (comment), and will continue to harp on about). It would be far easier to make decisions about the impacts of a proposed API change if there were before/after code samples for real-world use cases. |
On Mon, May 18, 2020 at 2:21 PM Justin Grant ***@***.***> wrote:
- Abseil Time
<https://github.com/abseil/abseil-cpp/blob/62cf6a70414e15b356ec4f712ca8758133674f28/absl/time/duration.cc#L26-L27>
(Google's C++ library that uses a similar object model to Temporal).
Interestingly, Abseil does similar "duration balancing" like Temporal while
still managing to support negative durations, so I assume they've figured
out the logic that'd be needed for balancing negative units which seems
like it'd be the hardest part of supporting negative durations in Temporal.
I'm afraid I don't grok "duration balancing". Still, the sentences you
refer to in `absl/time/duration.cc` only concern an implementation detail
... we could have represented a duration differently, and may still.
… |
Based on #139 and #156 the second thought is to eliminate ZonedDateTime & OffsetDateTime entirely.
I've tried that experiment at https://github.com/std-proposal/temporal/tree/reduced
Pros:
( @devjgm @devbww can you elaborate on learnings from abseil)
Similar question to before:
Give me all the reasons why ZonedDateTime & OffsetDateTime should actually be a thing
( @gibson042 please comment! )
The text was updated successfully, but these errors were encountered: