Brian has made the key points. I'd add that choosing a definition of long milliseconds that exactly matched the JDK was important in getting Joda-Time widely adopted.
That the JDK chooses to ignore leap seconds (as UNIX did) is one that annoys many time "experts" but doesn't impact most users - people don't tend to care much about leap seconds. JSR-310 will allow people to care if they want to. It also properly defines the meaning of 1970-01-01 when leap-second UTC doesn't start until 1972. Stephen On 12 July 2010 15:24, Brian S O'Neill <[email protected]> wrote: > 1. The Java and Joda-time epoch are the same -- Unix time with > millisecond precision. > > 2. Lack of leap seconds simply means that if you wanted to know the > number of seconds elapsed between now and some datetime in the past, it > would be off a little bit. Joda-time assumes that the length of a day > (ignoring timezones) is always 86400 seconds. > > 3. Parsing a datetime string would be ambiguous only if the leap second > was included in it. Ordinarily, the seconds field is only 0..59, but a > leap second (or two) allows 0..61. > > 4. Publishing the epoch makes it much easier to convert to different > formats and perform calculations. Otherwise, the only approach would be > to extract calendar type, time zone, era, year, month, day, hour, > minute, second, millis always. Converting between calendar systems is an > amazing challenge if these are the only exposed values. > > You should probably read the jsr 310 threads. All of these questions > come up again and again. > > https://jsr-310.dev.java.net/servlets/SummarizeList?listName=dev > > > On 2010-07-12 03:11 AM, Winston Gutkowski wrote: >> Dear Joda experts, >> >> >> I've been contributing to a long, but ultimately rather fruitless, thread on >> the >> Sun Java forums about the java.util.Date class, and was hoping that one of >> your >> experts might be able to answer a few questions for me: >> >> 1. The published epoch for the Date class is given as 1/1/1970 00:00:00 GMT >> (I >> notice Joda's DateTime epoch specifies Zulu time, which I assume amounts to >> the >> same thing). When exactly is this in terms of UTC, which was not standardized >> until 1972? Or do they both in fact use "1/1/1970 00:00:00 UTC proleptic", as >> Unix time does? >> >> 2. The Joda FAQ states that Joda time does not support leap seconds. Does >> this >> mean that Joda's 'ticker' (and therefore presumably Java's) adjusts for this >> in >> some way, like Unix's; or simply that leap seconds are ignored for the >> purposes >> of displaying human-readable timestamps? >> >> >> 3. If the answer to Q2 is "the latter", what are the rules for parsing a date >> string that might be ambiguous? >> >> 4. What was Joda's rationale for publishing its DateTime epoch? I've been >> arguing that there was no good reason for Java's Date class to do so, since >> it >> >> (a) Anchors the date from an instant that people believe they "understand". >> (b) Encourages buggy conversion methods written in the mistaken belief that >> it's >> "simple". >> (c) Prevents the epoch from being changed in the event of a new time >> standard, >> or simply to make internal calculations more efficient. >> >> Thanks in advance for any answers. >> >> Winston Gutkowski >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Joda-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/joda-interest > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Joda-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/joda-interest
