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
Re: Putting it all together [message #186228 is a reply to message #186225] Sat, 21 June 2014 09:15 Go to previous messageGo to previous message
gordonb.zp2md is currently offline  gordonb.zp2md
Messages: 1
Registered: June 2014
Karma:
Junior Member
> 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. Second,
MySQL doesn't like imprecise dates, such as only a year being known.
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".

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. These should be DATE types for efficient sorting
and date arithmetic. 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. You might need to try extening the Gregorian calendar
backwards to avoid death before birth and other anomalies.
[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: Fri Nov 22 01:13:19 GMT 2024

Total time taken to generate the page: 0.05662 seconds