Thanks for the response Stephen.  It confirmed what I managed to figure
out on my own in the mean time.

Actually what helped me most was reading
http://joda-time.sourceforge.net/key_instant.html and
http://joda-time.sourceforge.net/key_partial.html.  It pointed out that
LocalDateTime, LocalDate, and LocalTime are all derived from Partial,
while DateTime is an Instant.  The deprecated YearMonthDay and TimeOfDay
classes were/are also Partials.  

It seems like this means that DateTime always maps to a universal
instant: 8 am PST as a DateTime would be the same as a DateTime for 9 am
MST.  A LocalDateTime for 8 am in the PST is not distinguishable from a
LocalDateTime for 8 am MST since both would be for 8 am.  
i.e.

DateTime dt1, dt2;
LocalDateTime ldt1, ldt2, ldt3;

dt1 = new DateTime(2007, 12, 31, 12, 0, 0, 0,
DateTimeZone.forID("Etc/GMT+0"));
dt2 = new DateTime(2007, 12, 31, 10, 0, 0, 0,
DateTimeZone.forID("Etc/GMT+2"));
assertEquals(dt1.getMillis(), dt2.getMillis());
// although assertEquals(dt1, dt2); fails(?), when I originally expected
it to pass.

dt1 = new DateTime(2007, 12, 31, 12, 0, 0, 0,
DateTimeZone.forID("Etc/GMT+0"));
dt2 = new DateTime(2007, 12, 31, 12, 0, 0, 0,
DateTimeZone.forID("Etc/GMT+3"));
assertNotSame(dt1, dt2);
ldt1 = dt1.toLocalDateTime();
ldt2 = dt2.toLocalDateTime();
assertEquals(ldt1, ldt2);
ldt3 = new LocalDateTime(2007, 12, 31, 12, 0, 0, 0);
assertEquals(ldt1, ldt3);

One thing I still find a bit confusing is the following statement from
the API javadocs for LocalDateTime: 
"Internally, LocalDateTime holds the datetime as milliseconds from
1970-01-01T00:00:00. This represents the local millisecond count which
differs from the epoch-based millisecond value in a ReadableInstant
implementation by the amount of the zone offset."  
First of all, it is ambiguous what the "1970-01-01T00:00:00" refers to -
is it in UTC or in the local time zone?  Secondly, it appears to suggest
that LocalDateTime contains a millisecond count, yet there is no
LocalDateTime.getMillis() and LocalDateTime is a Partial not an Instant
so I don't understand why it would have a millisecond count at all.  The
only apparent way to get a millisecond count for a LocalDateTime is to
convert it to a DateTime, which means a time zone is introduced either
implicitly or explicitly.  
I think what the javadocs are trying to say is that the LocalDateTime
uses the millisecond count from "1970-01-01T00:00:00" in the local time
zone for its internal implementation. This would mean that the
millisecond count for a LocalDateTime and a DateTime constructed from
the same year/month/day/hour/minute/second/millisecond numbers would
differ by the millisecond offset between the current default time zone
and UTC.

I find the similar statement in the DateTime javadocs to be clear and
unambiguous: "DateTime is the standard implementation of an unmodifiable
datetime class. It holds the datetime as milliseconds from the Java
epoch of 1970-01-01T00:00:00Z."  

It might be less confusing if the paragraph in the LocalDateTime
javadocs that mentions the millisecond count were just dropped.  It
seems like it is a bit of a red herring.  It also might help to link the
javadocs for LocalDate, LocalTime, LocalDateTime, DateTime back to the
user documentation for Partial and Instant.

Neil


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Stephen Colebourne
Sent: August 3, 2007 10:11 AM
To: Discussion of the Joda project
Subject: Re: [Joda-interest] Question about LocalDate, LocalTime,and
LocalDateTime.

Neil.Martin wrote:
> I am unsure if LocalDateTime is intended to replace DateTime.  In the 
> javadocs for YearMonthDay and TimeOfDay it explicitly states that they

> are replaced by LocalDate and LocalTime respectively.  However I 
> cannot find anything about DateTime being replaced by LocalDateTime.  
> I have been switching usage to the Local* classes and was wondering if

> I should be switching from DateTime to LocalDateTime.

LocalDateTime represents a date and a time *without* a time-zone.
DateTime represents a date and a time *with* a time-zone.

Which object you use depends on whether you need to represent a datetime
with or without time-zone.

Stephen

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Joda-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Joda-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest

Reply via email to