Default value for date/time (original) (raw)

Brian Goetz brian.goetz at oracle.com
Mon May 7 19:02:46 UTC 2018

Note that there are really two questions here. One is that of the default bit pattern in the representation. The other is the semantics of that bit pattern.

As John says, the first is largely a forced move; the second is under the control of the programmer.

Sent from my MacBook Wheel

On May 7, 2018, at 2:27 PM, John Rose <john.r.rose at oracle.com> wrote:

On May 7, 2018, at 5:06 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

There is an implicit desire in adding value types that classes like LocalDate can be treated as value types. But one of the requirements of value types is that they have a default value. But what should this be? For LocalDate, possible candidates might be - LocalDate.of(1970, 1, 1) - LocalDate.of(1, 1, 1) - LocalDate.of(2000, 1, 1) - LocalDate.MIN - LocalDate.MAX - LocalDate.now() But these are all poor choices IMO. Ultimately, dates are not like numbers - there isn't a meaningful default like zero. I suppose we'll have to use 1970-01-01 as it is traditional in Java, but it doesn't really have meaning. I'd be interested in hearing if there are any other choices or views? (I think this problem of no sensible default value may well occur for other value types.) Stephen The VM mandates that the all-zero encoding must be accepted by all value types. This is a forced move as you probably know. We have to define what this expression produces: LocalDate dflt = (new LocalDate[1])[0]; And we won't allow the value type itself to define an ad hoc default, because the implementation costs are high and the programmer convenience is marginal. I suggest that, for LocalDateTime, the required default (all-zero) throw exceptions for all component accessors. Alternatively, the zeroes could be taken to encode a "dumb" date like 1970-01-01. — John

More information about the valhalla-dev mailing list