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

Stephen Colebourne scolebourne at joda.org
Mon May 7 23:08:04 UTC 2018

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

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];

null? throws an exception? (ie. the default can't be observed)

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.

LocalDate objects are always valid - you can't create one representing the 31st February for example. So having an "instance" that exists in a local variable but is invalid, and throws from all methods seems pretty terrible.

Structuring the internal data such that all zeroes represents 1970-01-01 and that no other bit pattern represents that date would also be a bit painful (not too painful in this case, but I could imagine other value types where it would be). In essence, there would have to be a yearMinus1970, 'monthMinusOneanddayMinusOnefield instead of ayear` field - not very "codes like a class". I would have naturally expected that the choice of default was under programmer control, but if it can't then so be it.

Maybe what I'm asking is whether nullable value types are feasible, but I'm certain I don't understand all the associated trade offs.

thanks Stephen

More information about the valhalla-dev mailing list