[mb-users] [unknown date]

[Bogdan Butnaru]

On Jan 11, 2008 8:04 PM, Brian Schweitzer
<brian.brianschweitzer at gmail.com> wrote:
> > This seems to make more sense, I would hope that we've actually fixed
> > the problem by then ;) I'm not sure if the db can actually hold years
> > that high however. 2020 should be enough.
> >
> >
>
> Can I quote you on that in 12 years?  :D
>
> Seriously, I'd prefer to select something just utterly outside of any
> reasonable scope of time.  I wonder, though...  Isn't 0000 technically a
> year?

If by "technically a year" you mean an actual date, then no. AFAIK the
first year of this era is 1 AD, preceded by  1 BC. So if you mean we
can use to mean "no year", then you're right.

  I don't know if the database can handle it, but if I understand
> correctly, the database uses 00 for the month and/or day if those fields are
> empty, and if day/month = 00, it just shows the field as blank.  Would
> storing the year as 0000 if the field is blank, then if year = 0000, display
> just the blank instead of year work to still let the server hinge events on
> the year, but also still allow support for no-date events?  (I have no idea
> if there's something inherent to that idea that the server just cannot
> handle...)

If I understand you correctly, then that's how it should work: use
0000-00-00 for "no date known", and any other value as a date. If
someone is willing, we could add individual rules for every media (eg,
no CDs released before 1970-something (I can't remember), no wax
cylinders before 1887), and another generic warning for cases where no
release media is picked (ie, if a release date is before 1900 or after
this year, display a warning and ask the user to enter nothing if
they're not very sure).

-- 
Bogdan Butnaru — bogdanb at gmail.com
"I think I am a fallen star, I should wish on myself." – O.