...
[13:18:26 CDT(-0500)] <drewwills> it seems that "final LocalDate startDate = start.toLocalDate();" gives you a calendar date w/o any TZ info
[13:18:53 CDT(-0500)] <EricDalquist> right
[13:18:56 CDT(-0500)] <EricDalquist> but if you look in joda time
[13:19:08 CDT(-0500)] <EricDalquist> it creates that local date using the TZ of the start DateTime object
[13:19:15 CDT(-0500)] <drewwills> and "start.toLocalTime()" gives you an hour:min:sec of the day, also without any TZ attached
[13:20:35 CDT(-0500)] <drewwills> you can't ask a LocalDate the question getTimezone()
[13:20:44 CDT(-0500)] <EricDalquist> right
[13:20:58 CDT(-0500)] <EricDalquist> but if you look at how toLocalDate is implemented
[13:21:00 CDT(-0500)] <drewwills> no method for that, which leaves me to think it's "detached" from the concept of timezone
[13:21:02 CDT(-0500)] <EricDalquist> it does:
[13:21:46 CDT(-0500)] <EricDalquist> new LocalDate(start.getMillis(), start.getChronology());
[13:21:55 CDT(-0500)] <EricDalquist> and chronology includes the TZ
[13:22:14 CDT(-0500)] <EricDalquist> so it is creating that LocalDate using the TZ of the start DateTime
[13:23:52 CDT(-0500)] <drewwills> https://gist.github.com/drewwills/5556362
[13:24:51 CDT(-0500)] <drewwills> i end up with "start.toLocalTime()=00:00:00.000" and "end.toLocalTime()=23:59:59.000" (no TZ adjustment)
[13:25:53 CDT(-0500)] <drewwills> NB: that was after I changed from UTC >> local time in the test
[13:26:01 CDT(-0500)] <drewwills> i should undo that and re-run it
[13:28:19 CDT(-0500)] <drewwills> there – updated