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

Pull Request: OffsetDateTime.SwitchOffset #246

Closed
GoogleCodeExporter opened this Issue Mar 15, 2015 · 14 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter

GoogleCodeExporter commented Mar 15, 2015

This seems missing from the API.  Please merge.  Thanks.

https://code.google.com/r/mj1856-noda-time/source/detail?r=a487d4ab0c92fc34f42e9
d4f97e00513fce2510a

Original issue reported on code.google.com by mj1856 on 8 Sep 2013 at 11:01

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Hmm. I think I'd want a different name - it's not obvious to me just from the 
name what the difference between the existing WithOffset and SwitchOffset is.

How about WithOffsetRetainInstant?

Original comment by jonathan.skeet on 9 Sep 2013 at 7:03

  • Added labels: Type-Enhancement
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

I think both are terrible names :-).  This doesn't sound like a _particularly_ 
frequently-used method, though I think that we should be able to do it.

(Jon: WithOffset is only on LocalDateTime, not e.g. OffsetDateTime, btw.)

In terms of parallels, I note:
- Instant has In{Utc,Zone} to augment an instant with a given zone.
- OffsetDateTime has WithCalendar, which keeps the instant.
(- LocalDateTime also has WithCalendar, but I must admit that I have no idea 
what it does given the documentation!)
- LocalDateTime has WithOffset, which constructs an OffsetDateTime by 
calculating the correct instant.
- ZonedDateTime has WithZone, which keeps the instant.

I think that either or both of the following would be reasonable:
1. Instant.InOffset(Offset), allowing a switch via 
offsetDateTime.ToInstant().InOffset(offset).
2. OffsetDateTime.WithOffset(Offset), as a shortcut to #1.

One possibly argument against #2: something like:

localDateTime.WithOffset(offset1).WithOffset(offset3)
and
localDateTime.WithOffset(offset2).WithOffset(offset3)

would result in different values.  If we instead wrote that as #1 requires:

localDateTime.WithOffset(offset1).ToInstant().InOffset(offset3)
and
localDateTime.WithOffset(offset2).ToInstant().InOffset(offset3)

then I think it might be a bit clearer that that's the case.

Original comment by malco...@google.com on 9 Sep 2013 at 11:05

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

[deleted comment]
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Eek, sorry about that - assumed we had WithOffset.

Note that going via an Instant is difficult in terms of it not having a 
calendar system.

Given that we model an OffsetDateTime as "a LocalDateTime and an Offset" I'd 
prefer WithOffset to keep the same LocalDateTime rather than the same Instant. 
I do see how that doesn't stack up well with the other methods we've got.

I suspect we want *both* methods ultimately, but more discussion required. The 
implementation is trivial both ways, of course.

Original comment by jonathan.skeet on 9 Sep 2013 at 12:32

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

This is how I am doing it currently, which just seems like a lot of hoops.

offsetDateTime.ToInstant().InZone(DateTimeZone.ForOffset(offset)).ToOffsetDateTi
me()

I chose the SwitchOffset name just because it popped into my head of seeing it 
in SQL Server - that's the exact name they use for this against their 
datetimeoffset type.

The .NET BCL DateTimeOffset has their function called ToOffset - but given that 
we have an Offset class, that didn't seem right.

I'm fine with the WithOffset name, or whatever you want to call it. :)

Original comment by mj1856 on 9 Sep 2013 at 8:56

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Instant.WithOffset has now been implemented, btw. Still not sure what to call 
the method on OffsetDateTime.

Original comment by jonathan.skeet on 8 Nov 2013 at 10:31

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 16 Nov 2013 at 2:39

  • Added labels: Milestone-unscheduled
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Looking at what we've got again, LocalDateTime.WithCalendar changes the values 
of other properties too - because it's the sensible thing to do - so I think 
WithOffset makes sense here. Will implement in a bit.

Original comment by jonathan.skeet on 31 Jan 2014 at 2:43

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Fixed in revision 21689340e192.

Original comment by jonathan.skeet on 31 Jan 2014 at 7:33

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

[deleted comment]
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

For some reason, this wasn't marked as fixed.  In any case, this came up in 
discussion recently, as we noticed that JSR-310's OffsetDateTime provides 
methods called withOffsetSameInstant() (=WithOffset() above) and 
withOffsetSameLocal().  Should we adopt those instead?

(Likewise, JSR-310 has Instant.atOffset() rather than our Instant.WithOffset(), 
but we already released that in 1.2, whereas the changes to OffsetDateTime 
haven't been released.)

Original comment by malcolm.rowe on 22 Feb 2014 at 11:03

  • Added labels: Milestone-1.3.0
  • Removed labels: Milestone-unscheduled
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Original comment by malcolm.rowe on 22 Feb 2014 at 11:03

  • Changed state: Accepted
@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

Personally I'm happy with what we've got now. `withOffsetSameLocal` is a pretty 
rare case, and it's really easy to implement clearly in Noda Time anyway:

    OffsetDateTime x = ...;
    OffsetDateTime y = x.LocalDateTime.WithOffset(newOffset);

So long as those using WithOffset know that it *does* retain the same instant 
(rather than the same local date/time), I think that's fine. But yes, we can 
definitely change it if we want :)

Personally I'm happy with Instant.WithOffset - AtOffset would sound odd, as 
"at" implies (to me) a particular time, not an offset.

Original comment by jonathan.skeet on 22 Feb 2014 at 4:47

@GoogleCodeExporter

This comment has been minimized.

GoogleCodeExporter commented Mar 15, 2015

I think we're now done with this:

LocalDateTime.WithOffset
Instant.WithOffset (overloaded to optionally accept a calendar system)
OffsetDateTime.WithOffset

I don't think anything else is needed, and I'm comfortable with the names.

Original comment by jonathan.skeet on 10 Apr 2014 at 7:34

  • Changed state: Fixed

@malcolmr malcolmr modified the milestone: 1.3.0 Mar 15, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment