FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Putting it all together
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Storing dates (was: Putting it all together) [message #186229 is a reply to message #186228] Sat, 21 June 2014 10:15 Go to previous messageGo to previous message
Thomas 'PointedEars'  is currently offline  Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma:
Senior Member
[F'up2 comp.databases.mysql

Gordon Burditt wrote in comp.lang.php and comp.databases.mysql:

> [“richard” wrote:]
>> Why would anyone store a date in a MySQL
>> database using any data type other than DATE or DATETIME?
>
> Believe it or not, there are (very rarely) good reasons to do that.
>
> Genealogy is one example. It has lots of dates MySQL won't accept.
> First, some people (such as English royalty) can trace their ancestry
> back before 1000 A.D., before the limit on the DATE type.

ACK.

> Second, MySQL doesn't like imprecise dates, such as only a year being
> known.

This can be solved by setting the unknown parts to 1 and have other fields
of the record specify the precision.

Also, there is the YEAR type (preferably used as YEAR(4)), but it only has a
range from 1901 to 2155:

<http://dev.mysql.com/doc/refman/5.6/en/year.html>

> Third, during a time when both the Julian and Gregorian calendars
> were in use, depending on location, you often see dates recorded
> as "5 January 1712/13" or "5 January 1712/3". You might also see
> "5 January 1712".

Same there.

> Since the Julian calendar as used in the English colonies that later
> became the United States used March 25 as the first day of the year,
> you can get ridiculous-looking records such as a child born: March
> 27, 1700, died: March 23, 1700 (not a mistake: the child lived
> almost a full year) and born: March 24, 1700, died: March 25, 1701
> (the child lived about 24 hours). Also, a date recorded as "the
> 6th day of the third month of 1699" might be referring to March or
> May.
>
> It may be best to treat all dates (birth, death, marriage, graduation,
> etc.) as ranges.

Depends.

> These should be DATE types for efficient sorting and date arithmetic.

That contradicts your premise that dates could be before 1000-01-01 CE. It
is usually the dates of birth and death of people born before that date that
are uncertain and require ranges. For example, Plato lived “[from] 428/427
or 424/423 BC[a] [to] 348/347 BC” (Wikipedia).

> It's also important to record the date(s) as stated in the source(s) as
> originally recorded, complete with accurate reproduction of spelling
> errors and in the original language, in text fields (or perhaps as an
> image). This is not redundant. You may have to do considerable research
> to set the DATE fields from the original source data that may be
> conflicting, imprecise, or ambiguous.

ACK. But that information should be stored in separate columns.

> You might need to try extening the Gregorian calendar backwards to avoid
> death before birth and other anomalies.

It has been done before. MySQL already does it, not least because the first
day of the Gregorian calendar is _not_ 0001-01-01 CE, but 1582-10-15 CE.

< https://en.wikipedia.org/wiki/Gregorian_calendar#Proleptic_Gregorian_calend ar>

This has nothing to do with PHP anymore. Please stop crossposting (without
F'up2).


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom(at)94(dot)75(dot)214(dot)39>
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: str_replace does not like empty quotes
Next Topic: SplFileObject always returns an extra "last" line -- why?
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Nov 21 21:24:47 GMT 2024

Total time taken to generate the page: 0.04146 seconds