Re: NULL values in sqlite

[Gabriel Charette]

+scheduler-dev (public) is the closest thing to a mailing list of people that care about Time that I can think of.

On Tue, Jan 10, 2023 at 6:05 PM Austin Sullivan <asu...@google.com> wrote:

+Gabriel Charette for context on https://crbug.com/1392437

If I were to add an email group to this email thread so that I could link it in a comment on that bug, which group would you recommend? Is there a group dedicated to Time code?

On Mon, Nov 21, 2022 at 10:36 AM Austin Sullivan <asu...@google.com> wrote:

I have an upcoming Code Health Rotation next month so maybe I can take a peek at it... :)

On Mon, Nov 21, 2022 at 10:31 AM Peter Kasting <pkas...@google.com> wrote:

On Mon, Nov 21, 2022 at 10:23 AM Austin Sullivan <asu...@google.com> wrote:

Thanks for the input, Peter. I can get on board with using optional<Time> if Time is conceptually just as a wrapper around an unsigned it.

Out of curiosity, have we considered giving base::Time a true "uninitialized" state? Or removing the default constructor to force the use of optional<Time>? Or at least updating the documentation to not explicitly encourage use of Time(0) as a null value?

The current documentation (see the comment on the default constructor) and API shape (see the is_null() method and its comment) are quite misleading if we expect Time(0) to be a valid (non-null) value.

Yeah, that feels like a footgun to me. I would support removing is_null() and updating docs for sure, and removing Time() if possible.

Based on the existence of things like https://bugs.chromium.org/p/chromium/issues/detail?id=576147 I suspect this might be challenging to do correctly. Still, it's worth considering.  I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1392437 .

Note, I am very unlikely to ever work on this :)

PK