Default value for date/time

[Stephen Colebourne]

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`, 'monthMinusOne` and `dayMinusOne` field
instead of a `year` 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