You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> What situation does this request make simpler?
Avoiding long property chains for little purpose.
To find out today's date in a particular zone, I currently have to use:
var date = clock.Now.InZone(zone).LocalDateTime.Date;
Ditto for time of day.
Three options suggest themselves:
1) var date = clock.Now.InZone(zone).Date;
2) var date = clock.Now.InZone(zone).LocalDate;
3) var date = clock.Now.InZone(zone).Local.Date;
In the first two options it would be adding new properties to ZonedDateTime -
either Date and Time, or LocalDate and LocalTime. In the third option it would
be adding "Local" as a synonym for "LocalDateTime", which works nicely here but
is a little bleh. Whatever we do for ZonedDateTime we should do for
OffsetDateTime too.
I *think* I prefer option 1, but equally emphasizing the "local" part is nice
too...
Original issue reported on code.google.com by jonsk...@google.com on 30 Jan 2013 at 11:25
The text was updated successfully, but these errors were encountered:
Option 1 seems like the most sensible to me: we already provide Year, Month,
Day, Hour, etc properties on both, which are clearly 'local' values, and so
also adding in the Date and TimeOfDay [presumably? q.v. LocalDateTime]
properties would make sense too; the return type and summary should make it
clear that they're local dates/times.
Original comment by malcolm.rowe on 30 Jan 2013 at 11:37
Yes, let's go with that then - and definitely TimeOfDay to match LocalDateTime.
I'd misremembered the name, but I definitely want them to match!
Will do it on the train tomorrow.
Original comment by jonsk...@google.com on 30 Jan 2013 at 11:39
Original issue reported on code.google.com by
jonsk...@google.com
on 30 Jan 2013 at 11:25The text was updated successfully, but these errors were encountered: