Default value for date/time

[Brian Goetz]

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