Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #13930 > unrolled thread

Putting it all together

Back to article view | Back to comp.lang.php

Contents

  Putting it all together richard <noreply@example.com> - 2014-06-20 10:20 -0400
    Re: Putting it all together Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-06-20 08:11 -0700
      Re: Putting it all together richard <noreply@example.com> - 2014-06-20 11:24 -0400
        Re: Putting it all together Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-20 17:15 +0000
        Re: Putting it all together Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-06-20 20:01 -0700
    Re: Putting it all together Jürgen Exner <jurgenex@hotmail.com> - 2014-06-20 08:21 -0700
    Re: Putting it all together Norman Peelman <npeelman@cfl.rr.com> - 2014-06-20 21:06 -0400
    Re: Putting it all together Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-21 03:02 +0000
    Re: Putting it all together Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-21 03:09 +0000
    Re: Putting it all together Jürgen Exner <jurgenex@hotmail.com> - 2014-06-20 20:13 -0700
      Re: Putting it all together richard <noreply@example.com> - 2014-06-20 23:34 -0400
        Re: Putting it all together Jürgen Exner <jurgenex@hotmail.com> - 2014-06-20 20:48 -0700
        Re: Putting it all together Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-06-20 21:00 -0700
        Re: Putting it all together Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-21 04:22 +0000
          Re: Putting it all together Jürgen Exner <jurgenex@hotmail.com> - 2014-06-20 22:11 -0700
            Re: Putting it all together Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-06-20 22:39 -0700
          Re: Putting it all together gordonb.zp2md@burditt.org (Gordon Burditt) - 2014-06-21 04:15 -0500
            Storing dates (was: Putting it all together) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-21 12:15 +0200
              Re: Storing dates richard <noreply@example.com> - 2014-06-21 11:10 -0400
                Re: Storing dates Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-21 17:42 +0000
                  Re: Storing dates richard <noreply@example.com> - 2014-06-21 14:28 -0400
                    Re: Storing dates Jürgen Exner <jurgenex@hotmail.com> - 2014-06-21 12:04 -0700
                    Re: Storing dates Doug Miller <doug_at_milmac_dot_com@example.com> - 2014-06-21 19:06 +0000
                      Re: Storing dates Tim Streater <timstreater@greenbee.net> - 2014-06-21 22:06 +0100
                        Re: Storing dates Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-21 17:09 -0400
                          Re: Storing dates Tim Streater <timstreater@greenbee.net> - 2014-06-21 22:33 +0100
                            Re: Storing dates Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-21 17:49 -0400
                            Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-22 14:38 +0200
                        Re: Storing dates Jürgen Exner <jurgenex@hotmail.com> - 2014-06-21 14:31 -0700
                          Re: Storing dates Tim Streater <timstreater@greenbee.net> - 2014-06-21 22:44 +0100
                          Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-22 14:59 +0200
                    Re: Storing dates Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-21 23:19 +0000
                    Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-22 08:53 +0200
                      Re: Storing dates "Erick T. Barkhuis" <erick.use-net@ardane.c.o.m> - 2014-06-22 08:03 +0000
                        Re: Storing dates Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-22 09:29 -0400
                          Re: Storing dates "Erick T. Barkhuis" <erick.use-net@ardane.c.o.m> - 2014-06-22 14:24 +0000
                            Re: Storing dates Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-22 10:32 -0400
                              Re: Storing dates "Erick T. Barkhuis" <erick.use-net@ardane.c.o.m> - 2014-06-22 14:45 +0000
                              Re: Storing dates Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-22 19:44 +0000
                            Re: Storing dates Jürgen Exner <jurgenex@hotmail.com> - 2014-06-22 08:26 -0700
                          Re: Storing dates gordonb.q26od@burditt.org (Gordon Burditt) - 2014-06-22 10:00 -0500
                        Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-22 16:47 +0200
                          Re: Storing dates richard <noreply@example.com> - 2014-06-22 13:55 -0400
                            Re: Storing dates Jürgen Exner <jurgenex@hotmail.com> - 2014-06-22 12:31 -0700
                              Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-24 22:27 +0200
                            Re: Storing dates Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-22 19:52 +0000
                            Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-22 21:52 +0200
                      Re: Storing dates richard <noreply@example.com> - 2014-06-22 14:05 -0400
                        Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-22 21:56 +0200
                          Re: Storing dates richard <noreply@example.com> - 2014-06-22 22:46 -0400
                            Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-23 08:11 +0200
                              Re: Storing dates richard <noreply@example.com> - 2014-06-23 02:37 -0400
                                Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-23 11:10 +0200
                                Re: Storing dates Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-06-23 06:50 -0700
                                  Re: Storing dates richard <noreply@example.com> - 2014-06-23 11:13 -0400
                                    Re: Storing dates Evan Platt <evan@theobvious.espphotography.com.invalid> - 2014-06-23 09:13 -0700
                                      Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-23 22:33 +0200
                          Re: Storing dates richard <noreply@example.com> - 2014-06-22 23:04 -0400
                            Re: Storing dates Arno Welzel <usenet@arnowelzel.de> - 2014-06-23 08:12 +0200
                              Re: Storing dates Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-23 16:45 +1000
                                Re: Storing dates richard <noreply@example.com> - 2014-06-23 07:58 -0400
                                  Re: Storing dates Jürgen Exner <jurgenex@hotmail.com> - 2014-06-23 09:50 -0700
                                    Re: Storing dates Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-23 19:02 +0200
                                  Re: Storing dates Geoff Muldoon <geoff.muldoon@trap.gmail.com> - 2014-06-24 12:00 +1000
                                Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-24 22:38 +0200
                        Re: Storing dates Jürgen Exner <jurgenex@hotmail.com> - 2014-06-22 15:30 -0700
                          Re: Storing dates "Peter H. Coffin" <hellsop@ninehells.com> - 2014-06-22 20:10 -0500
            Re: Putting it all together Jürgen Exner <jurgenex@hotmail.com> - 2014-06-21 03:34 -0700
        Re: Putting it all together Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-21 10:23 +0000
        Re: Putting it all together bill <william@TechServSys.com> - 2014-06-21 07:03 -0400
          Re: Putting it all together Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-21 15:11 +0000
        Re: Putting it all together "Peter H. Coffin" <hellsop@ninehells.com> - 2014-06-21 10:57 -0500
        Re: Putting it all together Arno Welzel <usenet@arnowelzel.de> - 2014-06-22 08:45 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#13930 — Putting it all together

http://mroldies.net/radio/tracker4.php

For this excercise, I decided to order by artist.
I'll do it by date later.

I also gave up on trying to strip the slashes from the data as it got
inserted into the table.
I decided it would be easier to remove the slashes on the output.
stripslashes() worked rather nicely.

[toc] | [next] | [standalone]

#13931

On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com>
wrote:

>http://mroldies.net/radio/tracker4.php
>
>For this excercise, I decided to order by artist.
>I'll do it by date later.

You mean once Lew responds to your e-mail?

Poor Lew. Might as well quit your day job. When bullis posts here and
everyone refuses to help him, he'll be e-mailing you.
-- 
To reply via e-mail, remove The Obvious and .invalid from my e-mail address.

[toc] | [prev] | [next] | [standalone]

#13933

On Fri, 20 Jun 2014 08:11:51 -0700, Evan Platt wrote:

> On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com>
> wrote:
> 
>>http://mroldies.net/radio/tracker4.php
>>
>>For this excercise, I decided to order by artist.
>>I'll do it by date later.
> 
> You mean once Lew responds to your e-mail?
> 
> Poor Lew. Might as well quit your day job. When bullis posts here and
> everyone refuses to help him, he'll be e-mailing you.

One stupid ignorant troll you are.
FYI, asswipe, Lew said to eamil him for further help.
I do not do email unless asked to.

Where have you had constructive input, to anything, in either group?
No where.

www.espphotography.com
Now conveninetly parked.
What a joke.

For you Mr.Miller, don't even consider telling me I can't call evan an
asswipe. Because he is one.

[toc] | [prev] | [next] | [standalone]

#13937

richard <noreply@example.com> wrote in news:mmz063kddiet.1opy7snnf1veg.dlg@
40tude.net:

> For you Mr.Miller, don't even consider telling me I can't call evan an
> asswipe. Because he is one.

And you wonder why people don't like you....

[toc] | [prev] | [next] | [standalone]

#13939

On Fri, 20 Jun 2014 11:24:48 -0400, richard <noreply@example.com>
wrote:

>One stupid ignorant troll you are.

Pot, kettle.

>FYI, asswipe, Lew said to eamil him for further help.
>I do not do email unless asked to.

Yeah, and I bet Lew's going to regret telling you that when you start
e-mailing him every day.

>Where have you had constructive input, to anything, in either group?
>No where.

And where have you?

>www.espphotography.com
>Now conveninetly parked.
>What a joke.

And how's your dome home coming? You know, the one you said would be
done in a year - 3 years ago?

What a joke.

>For you Mr.Miller, don't even consider telling me I can't call evan an
>asswipe. Because he is one.

bullis, stick to something you're good at. You know, like coloring.
-- 
To reply via e-mail, remove The Obvious and .invalid from my e-mail address.

[toc] | [prev] | [next] | [standalone]

#13932

On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com> wrote
in comp.databases.mysql:

>http://mroldies.net/radio/tracker4.php
>For this excercise, I decided to order by artist.
>I'll do it by date later.

Does this have anything to do with SQL?

>I also gave up on trying to strip the slashes from the data as it got
>inserted into the table.
>I decided it would be easier to remove the slashes on the output.
>stripslashes() worked rather nicely.

There is a SQL function stripslashes()? I didn't know that.
Or did you mean TRIM()?

jue

[toc] | [prev] | [next] | [standalone]

#13938

On 06/20/2014 10:20 AM, richard wrote:
> http://mroldies.net/radio/tracker4.php
>
> For this excercise, I decided to order by artist.
> I'll do it by date later.
>
> I also gave up on trying to strip the slashes from the data as it got
> inserted into the table.
> I decided it would be easier to remove the slashes on the output.
> stripslashes() worked rather nicely.
>


#1 - mysqli_real_escape_string();

#2 - ORDER BY artist, title ASC


-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

[toc] | [prev] | [next] | [standalone]

#13940

On Fri, 20 Jun 2014 10:20:59 -0400, richard wrote:

> For this excercise, I decided to order by artist.
> I'll do it by date later.

Having discovered that your past refusal to store date information in a 
database as date information means that the database can't sort it in 
date order, you're giving up on this one.

Note that you have in fact been given an example of how to get mysql to 
sort your richardian string representation of date by actual date order, 
by adding a conversion in the order by clause that converts the richardian 
string representation of date into a true date that mysql can sort on. 
When you ask how to do this again in a few days / weeks / months / aeons, 
I reserve the non-exclusive[1] right to say "see the previous discussion 
about this".

> I also gave up on trying to strip the slashes from the data as it got
> inserted into the table.

Given that we're talking about mysql, presumably the table you're 
referring to is the database table. You should probably be using the 
appropriate quoting and escaping functions that exist in the programming 
environment that you are using to generate sql, rather than inventing 
your own based on your flawed understanding of what needs to be done.

[1] Who wants shares in this?

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#13941

On Fri, 20 Jun 2014 10:20:59 -0400, richard wrote:

> http://mroldies.net/radio/tracker4.php

I only found the following errors, but I only had a quick look, so there 
may be more:

1) & character not sent as html entity
2) backslash character in the band name "Herman's Hermits"

So it looks like you need to visit that drawing board again.

Note that there are special functions in certain programming languages to 
(a) automatically insert html entities into text as needed, and (b) 
automatically add backslashes into text being inserted into mysql 
databases as needed. If you used these functions correctly, some of your 
problems might be solved. Other problems, well it looks like being richard 
isn't fixable.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#13942

On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com> wrote
in comp.databases.mysql:

>For this excercise, I decided to order by artist.
>I'll do it by date later.

That should be as simple as 
	SELECT .... FROM ...... ORDER BY date

Of course that assumes that date is of type date (or datetime) as any
sane person would store a date.

jue

[toc] | [prev] | [next] | [standalone]

#13943

On Fri, 20 Jun 2014 20:13:10 -0700, Jürgen Exner wrote:

> On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com> wrote
> in comp.databases.mysql:
> 
>>For this excercise, I decided to order by artist.
>>I'll do it by date later.
> 
> That should be as simple as 
> 	SELECT .... FROM ...... ORDER BY date
> 
> Of course that assumes that date is of type date (or datetime) as any
> sane person would store a date.
> 
> jue

what if use Julian dates?
that throws all of your damn bullshit right down the drain don't it?

[toc] | [prev] | [next] | [standalone]

#13944

On Fri, 20 Jun 2014 23:34:19 -0400, richard <noreply@example.com> wrote
in comp.databases.mysql:

>On Fri, 20 Jun 2014 20:13:10 -0700, Jürgen Exner wrote:
>
>> On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com> wrote
>> in comp.databases.mysql:
>> 
>>>For this excercise, I decided to order by artist.
>>>I'll do it by date later.
>> 
>> That should be as simple as 
>> 	SELECT .... FROM ...... ORDER BY date
>> 
>> Of course that assumes that date is of type date (or datetime) as any
>> sane person would store a date.
>
>what if use Julian dates?
>that throws all of your damn bullshit right down the drain don't it?

If done correctly it is still as simple as 
	SELECT .... FROM ...... ORDER BY date
Of course you have the additional trouble of converting back and forth
between Julian and Gregorian date and time because there aren't many
people who could interpret a Julian date, but that can certainly be
solved.

jue 

[toc] | [prev] | [next] | [standalone]

#13945

On Fri, 20 Jun 2014 23:34:19 -0400, richard <noreply@example.com>
wrote:

>what if use Julian dates?
>that throws all of your damn bullshit right down the drain don't it?

Wow, and you wonder why no one wants to help you.
-- 
To reply via e-mail, remove The Obvious and .invalid from my e-mail address.

[toc] | [prev] | [next] | [standalone]

#13946

richard <noreply@example.com> wrote in news:1v5cqtux7fm2t$.14sqgdhtzf3vw.dlg@
40tude.net:

> On Fri, 20 Jun 2014 20:13:10 -0700, Jürgen Exner wrote:
> 
>> On Fri, 20 Jun 2014 10:20:59 -0400, richard <noreply@example.com> wrote
>> in comp.databases.mysql:
>> 
>>>For this excercise, I decided to order by artist.
>>>I'll do it by date later.
>> 
>> That should be as simple as 
>>      SELECT .... FROM ...... ORDER BY date
>> 
>> Of course that assumes that date is of type date (or datetime) as any
>> sane person would store a date.
>> 
>> jue
> 
> what if use Julian dates?

Why on earth would you want to do *that*? Why would anyone store a date in a MySQL 
database using any data type other than DATE or DATETIME?

> that throws all of your damn bullshit right down the drain don't it?

There's one *more* thing you need to apologize for, Bullis.

And you wonder why nobody wants to help you.  How much longer will it be before you 
grasp the concept that the *external* *presentation* of date or date-time data can (and 
usually *should*) be different from the *internal* format in which it is stored?

[toc] | [prev] | [next] | [standalone]

#13947

On Sat, 21 Jun 2014 04:22:43 +0000 (UTC), Doug Miller
<doug_at_milmac_dot_com@example.com> wrote in comp.databases.mysql:
>richard <noreply@example.com> wrote in news:1v5cqtux7fm2t$.14sqgdhtzf3vw.dlg@
>40tude.net:
>> what if use Julian dates?
>
>How much longer will it be before you 
>grasp the concept that the *external* *presentation* of date or date-time data can (and 
>usually *should*) be different from the *internal* format in which it is stored?

Well, in this case here I *SERIOUSLY* hope that he does not present
Julian dates to the user, even if that is his internal format.

jue

[toc] | [prev] | [next] | [standalone]

#13948

On Fri, 20 Jun 2014 22:11:53 -0700, Jürgen Exner
<jurgenex@hotmail.com> wrote:

>Well, in this case here I *SERIOUSLY* hope that he does not present
>Julian dates to the user, even if that is his internal format.

Unix time is the way to go....
-- 
To reply via e-mail, remove The Obvious and .invalid from my e-mail address.

[toc] | [prev] | [next] | [standalone]

#13949

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

[toc] | [prev] | [next] | [standalone]

#13950 — Storing dates (was: Putting it all together)

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

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

[toc] | [prev] | [next] | [standalone]

#13957 — Re: Storing dates

On Sat, 21 Jun 2014 12:15:04 +0200, Thomas 'PointedEars' Lahn wrote:

> [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_calendar>
> 
> This has nothing to do with PHP anymore.  Please stop crossposting (without 
> F'up2).
> 
> 
> PointedEars

This is really getting hilarious.
You guys are bashing each other over the "proper use" of dates.
One says one thing, someone else comes along and say you're wrong.
Then gives a long winded diatribe as to why.

Ok smart people, try this one on for size.
A person is born on Ocober 4, 1582 (Julian) and dies on October
16,1582(Gregorian).
How long did he live?

Did you know that the monthly calendar as we know it today was actually
invented by the Romans? Not Pope Gregory?
Originally, the calendar had 10 months.
Each month named with Latin based numbering system.
Ergo, December being the tenth month.
October, the eighth month.

Who do the monhts July and August honor?
Julias Augustus Ceasar.

January and February were added by Numa Pompilius in 713 BC.
Februa is an ancient purification ritual.

As for the date usage on MY database tables, I am only using a date as a
reference. I really don't give a damn what your philosophy or ideals are
behind the so called "proper ways" of obtaining a date.

[toc] | [prev] | [next] | [standalone]

#13962 — Re: Storing dates

richard <noreply@example.com> wrote in news:1mddkhwt2mr0v$.1m6eithcu7iod.dlg@
40tude.net:

> As for the date usage on MY database tables, I am only using a date as a
> reference.

Patently false, as you have posted questions here asking for help resolving your problems in 
sorting by the date.

> I really don't give a damn what your philosophy or ideals are
> behind the so called "proper ways" of obtaining a date.
 
Which is exactly *why* you have problems sorting by the date.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web