FUDforum - خوراک RDF
http://fudforum.org/forum/index.php
Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186209&th=123544#msg_186209
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.]]>Mr Oldies2014-06-20T14:20:59-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186210&th=123544#msg_186210
noreply@example.com>
wrote:
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.]]>Evan Platt2014-06-20T15:11:51-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186211&th=123544#msg_186211
noreply@example.com> wrote
in comp.databases.mysql:
> 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]]>Jrgen Exner2014-06-20T15:21:29-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186212&th=123544#msg_186212
> 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.]]>Mr Oldies2014-06-20T15:24:48-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186216&th=123544#msg_186216
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....]]>Doug Miller2014-06-20T17:15:37-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186217&th=123544#msg_186217
> 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?-]]>Norman Peelman2014-06-21T01:06:26-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186218&th=123544#msg_186218
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.]]>Evan Platt2014-06-21T03:01:55-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186219&th=123544#msg_186219
> 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.
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]]>Denis McMahon2014-06-21T03:09:07-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186221&th=123544#msg_186221
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]]>Jrgen Exner2014-06-21T03:13:10-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186222&th=123544#msg_186222
> 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?]]>Mr Oldies2014-06-21T03:34:19-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186223&th=123544#msg_186223
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]]>Jrgen Exner2014-06-21T03:48:41-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186224&th=123544#msg_186224
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.]]>Evan Platt2014-06-21T04:00:28-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186225&th=123544#msg_186225
noreply@example.com> wrote in news:1v5cqtux7fm2t$.14sqgdhtzf3vw.dlg@
40tude.net:
> On Fri, 20 Jun 2014 20:13:10 -0700, Jrgen 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?]]>Doug Miller2014-06-21T04:22:43-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186226&th=123544#msg_186226
<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]]>Jrgen Exner2014-06-21T05:11:53-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186227&th=123544#msg_186227
<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.]]>Evan Platt2014-06-21T05:39:15-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186228&th=123544#msg_186228
> 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.]]>gordonb.zp2md2014-06-21T09:15:04-00:00Storing dates (was: Putting it all together)
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186229&th=123544#msg_186229
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:
> 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.
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>]]>Thomas 'PointedEars' 2014-06-21T10:15:04-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186230&th=123544#msg_186230
> what if use Julian dates?
> that throws all of your damn bullshit right down the drain don't it?
No, it doesn't change anything. As long as you store the dates using an
appropriate datatype for a date, you can sort by date.
Whether you call it date and store a datetime, or call it date and store
a julian date as a number from some arbitrary epoch is irrelevant.
Your mistake is in storing dates as strings and then expecting string
sort to sort them in date order.
You've been given a workround for this at least twice which would only
need you to wrap the column name date in your order by clause with a
suitable conversion function.
If instead you want to make more mistakes with julian dates, well who are
we to stand in your way. But when you start asking for help in sorting
out your julian dates, I reserve the non exclusive right to tell tell you
to see previous discussions and stop being an arse.
--
Denis McMahon, denismfmcmahon@gmail.com]]>Denis McMahon2014-06-21T10:23:29-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186231&th=123544#msg_186231
gordonb.zp2md@burditt.org (Gordon
Burditt) wrote in comp.databases.mysql:
>> Why would anyone store a date in a MySQL
>> database using any data type other than DATE or DATETIME?
>
> Since the Julian calendar [...]
Careful!
The Julian calender is something very different from a Julian day.
Now, having said that, the OP used the term "Julian date", and it is not
absoluty clear if he meant a day in the Julian calender or a Julian day.
But I interpret it as a Julian day, because a day in the Julian calender
makes even less sense.
jue]]>Jrgen Exner2014-06-21T10:34:53-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186232&th=123544#msg_186232
>
> what if use Julian dates?
> that throws all of your damn bullshit right down the drain don't it?
>
Actually using an ISO date would be better]]>bill2014-06-21T11:03:04-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186235&th=123544#msg_186235
> [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
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.]]>Mr Oldies2014-06-21T15:10:46-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186234&th=123544#msg_186234
> On 6/20/2014 11:34 PM, richard wrote:
>> what if use Julian dates?
>> that throws all of your damn bullshit right down the drain don't it?
> Actually using an ISO date would be better
Actually, in richard's case, forgetting about databases and using csv
text files instead would be better. And some sort of log file for his hit
tracker.
--
Denis McMahon, denismfmcmahon@gmail.com]]>Denis McMahon2014-06-21T15:11:34-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186237&th=123544#msg_186237
> 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 ?
I'll write it for you when you come up with an audio recording made
before October 1582.
--
"... I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last
week. Time to die...". -- Peter Gutmann in the scary.devil.monastery]]>Peter H. Coffin2014-06-21T15:57:16-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186241&th=123544#msg_186241
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.]]>Doug Miller2014-06-21T17:42:29-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186244&th=123544#msg_186244
> 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.
The problem with sorting is, it treats any value given as a string, then
determines which has the lowest value in total.
1
2
3
10
20
30
100
200
300
When you sort these numbers, how do they get displayed?
You will most likely see them displayed as:
1
10
100
2
Or maybe even as
100
10
1
2
In Liberty BASIC I got (as strings)
1
10
100
2
20
200
3
30
300]]>Mr Oldies2014-06-21T18:28:47-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186245&th=123544#msg_186245
noreply@example.com> wrote
in comp.databases.mysql:
> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>
>> 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.
>
> The problem with sorting is, it treats any value given as a string, then
> determines which has the lowest value in total.
> 1
> 2
> 3
> 10
> 20
> 30
> 100
> 200
> 300
A normal ascending numerical sort
> When you sort these numbers, how do they get displayed?
> You will most likely see them displayed as:
> 1
> 10
> 100
> 2
A normal ascending alphabetical sort
> Or maybe even as
> 100
> 10
> 1
> 2
This looks rather strange. Even if there were a trailing space character
then still "10 " would be sorted before "100 ". What sorting is this?
> In Liberty BASIC I got (as strings)
> 1
> 10
> 100
> 2
> 20
> 200
> 3
> 30
> 300
Again, a standard alphabetical sort.
So, which sorting order do you want? Numerical or alphabetical? And is
your data stored as number or as string? And if the type doesn't match
then what happened when you cast it into the right data type?
jue]]>Jrgen Exner2014-06-21T19:04:08-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186246&th=123544#msg_186246
noreply@example.com> wrote in
news:hzk4wa449wa$.3xtj0jkxz78o$.dlg@40tude.net:
> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>
>> 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.
>
> The problem with sorting is, it treats any value given as a
> string, then determines which has the lowest value in total.
Yes, I understand that. That results directly from storing dates as strings, and is exactly the
reason that everyone here has been telling you to store your dates in a column that has
the DATE datatype, not CHAR.
Your refusal to follow that advice -- apparently stemming from your inability to understand
that there even *are* datatypes other than NUMERIC and CHAR -- is the entire reason you
are having this sorting problem.]]>Doug Miller2014-06-21T19:06:20-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186249&th=123544#msg_186249
<doug_at_milmac_dot_com@example.com> wrote:
> richard <noreply@example.com> wrote in
> news:hzk4wa449wa$.3xtj0jkxz78o$.dlg@40tude.net:
>
>> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>>
>>> 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.
>>
>> The problem with sorting is, it treats any value given as a
>> string, then determines which has the lowest value in total.
>
> Yes, I understand that. That results directly from storing dates as strings,
> and is exactly the
> reason that everyone here has been telling you to store your dates in a
> column that has
> the DATE datatype, not CHAR.
>
> Your refusal to follow that advice -- apparently stemming from your inability
> to understand
> that there even *are* datatypes other than NUMERIC and CHAR -- is the entire reason you
> are having this sorting problem.
I have a field which contains values like 3.7, 4.2, etc. But when I
defined the field (in SQLite) I made it a TEXT field, forgetting that I
would need to be able to sort on that field.
My workaround is to convert the string to floating at the time of the
sort. In SQLite I do:
... ORDER BY ROUND(myfield,1);
which works just fine. Richard should look for something similar in
mysql.
--
"If you're not able to ask questions and deal with the answers without feeling
that someone has called your intelligence or competence into question, don't
ask questions on Usenet where the answers won't be carefully tailored to avoid
tripping your hair-trigger insecurities." - D M Procida, UCSM]]>Tim Streater2014-06-21T21:06:25-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186250&th=123544#msg_186250
> In article <XnsA353998B95688dougmilmaccom@78.46.70.116>, Doug Miller
> <doug_at_milmac_dot_com@example.com> wrote:
>
>> richard <noreply@example.com> wrote in
>> news:hzk4wa449wa$.3xtj0jkxz78o$.dlg@40tude.net:
>>> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>>>> > 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.
>>>> The problem with sorting is, it treats any value given as a
>>> string, then determines which has the lowest value in total.
>>
>> Yes, I understand that. That results directly from storing dates as
>> strings,
>> and is exactly the reason that everyone here has been telling you to
>> store your dates in a
>> column that has
>> the DATE datatype, not CHAR.
>> Your refusal to follow that advice -- apparently stemming from your
>> inability
>> to understand that there even *are* datatypes other than NUMERIC and
>> CHAR -- is the entire reason you are having this sorting problem.
>
> I have a field which contains values like 3.7, 4.2, etc. But when I
> defined the field (in SQLite) I made it a TEXT field, forgetting that I
> would need to be able to sort on that field.
>
> My workaround is to convert the string to floating at the time of the
> sort. In SQLite I do:
>
> ... ORDER BY ROUND(myfield,1);
>
> which works just fine. Richard should look for something similar in
> mysql.
>
Why don't you fix your database?
The way you're doing it cannot use an index and will call round() for
EVERY row in the sort.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-06-21T21:09:25-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186251&th=123544#msg_186251
<timstreater@greenbee.net> wrote in comp.databases.mysql:
> I have a field which contains values like 3.7, 4.2, etc. But when I
> defined the field (in SQLite) I made it a TEXT field, forgetting that I
> would need to be able to sort on that field.
>
> My workaround is to convert the string to floating at the time of the
> sort. In SQLite I do:
>
> ... ORDER BY ROUND(myfield,1);
>
> which works just fine.
Yes, that is a very well-known workaround commonly known as casting.
> Richard should look for something similar in
> mysql.
If he is using Julian days, then yes. Of course he could and should have
used a numerical type for this field in the first place. Then as you
discovered yourself he would not have to cast the value to a different
type.
If he is using a textual representation of a Julian calender date then
no. There he is completely on his own.
And if he had been using DATE or DATETIME then there wouldn't even be
this discussion.
jue]]>Jrgen Exner2014-06-21T21:31:28-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186252&th=123544#msg_186252
1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:
> On 6/21/2014 5:06 PM, Tim Streater wrote:
>> In article <XnsA353998B95688dougmilmaccom@78.46.70.116>, Doug Miller
>> <doug_at_milmac_dot_com@example.com> wrote:
>>
>>> richard <noreply@example.com> wrote in
>>> news:hzk4wa449wa$.3xtj0jkxz78o$.dlg@40tude.net:
>>>> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>>>> >> 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.
>>>> > The problem with sorting is, it treats any value given as a
>>>> string, then determines which has the lowest value in total.
>>>
>>> Yes, I understand that. That results directly from storing dates as
>>> strings,
>>> and is exactly the reason that everyone here has been telling you to
>>> store your dates in a
>>> column that has
>>> the DATE datatype, not CHAR.
>>> Your refusal to follow that advice -- apparently stemming from your
>>> inability
>>> to understand that there even *are* datatypes other than NUMERIC and
>>> CHAR -- is the entire reason you are having this sorting problem.
>>
>> I have a field which contains values like 3.7, 4.2, etc. But when I
>> defined the field (in SQLite) I made it a TEXT field, forgetting that I
>> would need to be able to sort on that field.
>>
>> My workaround is to convert the string to floating at the time of the
>> sort. In SQLite I do:
>>
>> ... ORDER BY ROUND(myfield,1);
>>
>> which works just fine. Richard should look for something similar in
>> mysql.
>
> Why don't you fix your database?
>
> The way you're doing it cannot use an index and will call round() for
> EVERY row in the sort.
I'd have to ask a number of users to convert their data when they next
upgrade the software. Trouble is in SQLite you can't just redefine a
table column to be a different type; ALTER TABLE is somewhat limited.
I'd have to copy the whole table to another, DROP the first one, RENAME
the new one, VACUUM the database to get its size down. OK, it's doable,
but I'm replying on less-than-technically-savvy users to run a Terminal
script on their own machine to effect this change.
In my own use of the app, I've got 65 databases that an update script
would have to find, recursively in an arbitrary folder structure. One
user has 1000. The recursion part is actually easy, that app already
does that at startup to verify that the user hasn't moved some
databases around by hand while the app wasn't running. I just feel a
shade nervous about distant people (i.e., not me) running a one-off
script.
In richard's case, it didn't sound like he has a huge number of rows,
so it struck me that a workaround wouldn't have much of a performance
impact. In mine, the column in question is unlikely to be a popular one
for sorting.
--
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf]]>Tim Streater2014-06-21T21:33:25-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186253&th=123544#msg_186253
d3ubq91a9ufstpi1fp963r54684sue6cr9@4ax.com>, Jürgen Exner
<jurgenex@hotmail.com> wrote:
> On Sat, 21 Jun 2014 22:06:25 +0100, Tim Streater
> <timstreater@greenbee.net> wrote in comp.databases.mysql:
>> I have a field which contains values like 3.7, 4.2, etc. But when I
>> defined the field (in SQLite) I made it a TEXT field, forgetting that I
>> would need to be able to sort on that field.
>>
>> My workaround is to convert the string to floating at the time of the
>> sort. In SQLite I do:
>>
>> ... ORDER BY ROUND(myfield,1);
>>
>> which works just fine.
>
> Yes, that is a very well-known workaround commonly known as casting.
Are you implying that I might instead do:
... ORDER BY CAST (myfield AS REAL);
?
--
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf]]>Tim Streater2014-06-21T21:44:56-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186254&th=123544#msg_186254
> In article <lo4sa4$h1p$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
>
>> On 6/21/2014 5:06 PM, Tim Streater wrote:
>>> In article <XnsA353998B95688dougmilmaccom@78.46.70.116>, Doug Miller
>>> <doug_at_milmac_dot_com@example.com> wrote:
>>>> > richard <noreply@example.com> wrote in
>>>> news:hzk4wa449wa$.3xtj0jkxz78o$.dlg@40tude.net:
>>>> > On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>>>> > >> 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.
>>>> > > The problem with sorting is, it treats any value given as a
>>>> > string, then determines which has the lowest value in total.
>>>>
>>>> Yes, I understand that. That results directly from storing dates as
>>>> strings,
>>>> and is exactly the reason that everyone here has been telling you to
>>>> store your dates in a
>>>> column that has
>>>> the DATE datatype, not CHAR.
>>>> Your refusal to follow that advice -- apparently stemming from your
>>>> inability
>>>> to understand that there even *are* datatypes other than NUMERIC and
>>>> CHAR -- is the entire reason you are having this sorting problem.
>>>> I have a field which contains values like 3.7, 4.2, etc. But when I
>>> defined the field (in SQLite) I made it a TEXT field, forgetting that I
>>> would need to be able to sort on that field.
>>>> My workaround is to convert the string to floating at the time of the
>>> sort. In SQLite I do:
>>>> ... ORDER BY ROUND(myfield,1);
>>>> which works just fine. Richard should look for something similar in
>>> mysql.
>>
>> Why don't you fix your database?
>>
>> The way you're doing it cannot use an index and will call round() for
>> EVERY row in the sort.
>
> I'd have to ask a number of users to convert their data when they next
> upgrade the software. Trouble is in SQLite you can't just redefine a
> table column to be a different type; ALTER TABLE is somewhat limited.
> I'd have to copy the whole table to another, DROP the first one, RENAME
> the new one, VACUUM the database to get its size down. OK, it's doable,
> but I'm replying on less-than-technically-savvy users to run a Terminal
> script on their own machine to effect this change.
>
Or have a script do it for them.
> In my own use of the app, I've got 65 databases that an update script
> would have to find, recursively in an arbitrary folder structure. One
> user has 1000. The recursion part is actually easy, that app already
> does that at startup to verify that the user hasn't moved some
> databases around by hand while the app wasn't running. I just feel a
> shade nervous about distant people (i.e., not me) running a one-off
> script.
>
People do it every day. Just ensure everything is backed up before
doing any conversion.
> In richard's case, it didn't sound like he has a huge number of rows,
> so it struck me that a workaround wouldn't have much of a performance
> impact. In mine, the column in question is unlikely to be a popular one
> for sorting.
>
ANYTHING with richard is a problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-06-21T21:49:38-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186255&th=123544#msg_186255
> The problem with sorting is, it treats any value given as a string, then
> determines which has the lowest value in total.
It only treats it as a string because you've defined it as data of type
string.
If you had defined it as data of type date, then it would store it as
data of type date (provided you delivered the data to it in a format that
it recognised as valid for type date) and then sorting by date would work.
--
Denis McMahon, denismfmcmahon@gmail.com]]>Denis McMahon2014-06-21T23:19:42-00:00Re: Putting it all together
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186260&th=123544#msg_186260
> 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?
Then use
TO_DAYS(date)+1721060
in MySQL.
Or vice versa
FROM_DAYS(date-1721060)
to convert from julian date.
> that throws all of your damn bullshit right down the drain don't it?
Nope.
--
Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de]]>Arno Welzel2014-06-22T06:45:48-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186261&th=123544#msg_186261
> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>
>> 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.
>
> The problem with sorting is, it treats any value given as a string, then
> determines which has the lowest value in total.
> 1
> 2
> 3
> 10
> 20
> 30
> 100
> 200
> 300
That's why *thinking* about how to store information is important.
Even if you don't like to use a date datatype you should store the date
values in a way that they can be used for sorting - so year first, then
month, then day and all with leading zeros:
2014-06-22 for the 22. June of 2014
1967-09-12 for the 9. September of 1967
--
Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de]]>Arno Welzel2014-06-22T06:53:17-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186262&th=123544#msg_186262
> 1967-09-12 for the 9. September of 1967
> BTW: This is why ISO 8601 had been invented
If that's the case, I don't like ISO 8601.
--
Erick]]>Erick T. Barkhuis2014-06-22T08:03:09-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186263&th=123544#msg_186263
Tim Streater wrote in comp.databases.mysql and comp.lang.php:
> Jerry Stuckle wrote:
>> On 6/21/2014 5:06 PM, Tim Streater wrote:
>>> I have a field which contains values like 3.7, 4.2, etc. But when I
>>> defined the field (in SQLite) I made it a TEXT field, forgetting that I
>>> would need to be able to sort on that field.
>>>
>>> My workaround is to convert the string to floating at the time of the
>>> sort. In SQLite I do:
>>>
>>> ... ORDER BY ROUND(myfield,1);
>>>
>>> which works just fine. Richard should look for something similar in
>>> mysql.
>>
>> Why don't you fix your database?
>>
>> The way you're doing it cannot use an index and will call round() for
>> EVERY row in the sort.
>
> I'd have to ask a number of users to convert their data when they next
> upgrade the software. Trouble is in SQLite you can't just redefine a
> table column to be a different type; ALTER TABLE is somewhat limited.
> I'd have to copy the whole table to another, DROP the first one, RENAME
> the new one, VACUUM the database to get its size down.
> OK, it's doable,
> but I'm replying on less-than-technically-savvy users to run a Terminal
> script on their own machine to effect this change.
If this is for an Android app (where SQLite is prevalent), you can use
built-in versioning support to migrate the SQLite database table structure
automagically with the next upgrade or downgrade. BTDT.
Otherwise you can have a table with corresponding version information. If
it is missing or the corresponding record is missing, you can assume the old
format and migrate the data accordingly. Several SQL-based applications do
this.
For example, Magento (which by default is MySQL-InnoDB-based) holds the
version of an extension in the table `core_resource`, and you can write
migration scripts (named e.g. upgrade-$old_ver-$new_ver.php) that are
automatically run if the current version differs but matches $old_ver, and
the new extension version matches $new_ver, after which the version in
`core_resource` is updated automatically to $new_ver.
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>]]>Thomas 'PointedEars' 2014-06-22T12:38:46-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186264&th=123544#msg_186264
J�rgen Exner wrote in comp.databases.mysql and comp.lang.php:
^^^^^^^^^^^^
Please do not use non-ASCII characters (like umlauts) in header field
values unless you are prepared to properly MIME-encode them as RFC 5322, and
by reference RFC 5536, requires it. Forté Agent is not smart enough for
that, at least not the outdated version of it that you are using.
> On Sat, 21 Jun 2014 22:06:25 +0100, Tim Streater
> <timstreater@greenbee.net> wrote in comp.databases.mysql:
It's attribution *line*, _not_ attribution novel.
>> I have a field which contains values like 3.7, 4.2, etc. But when I
>> defined the field (in SQLite) I made it a TEXT field, forgetting that I
>> would need to be able to sort on that field.
>>
>> My workaround is to convert the string to floating at the time of the
>> sort. In SQLite I do:
>>
>> ... ORDER BY ROUND(myfield,1);
>>
>> which works just fine.
By coincidence.
> Yes, that is a very well-known workaround commonly known as casting.
In this case the value is cast to an IEEE-754 double, probably resulting in
different values.
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>]]>Thomas 'PointedEars' 2014-06-22T12:59:31-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186265&th=123544#msg_186265
> Arno Welzel:
>
>> 1967-09-12 for the 9. September of 1967
>> BTW: This is why ISO 8601 had been invented
>
> If that's the case, I don't like ISO 8601.
>
>
>
Why not, Erick? It's a good format which sorts naturally.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-06-22T13:29:54-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186267&th=123544#msg_186267
> On 6/22/2014 4:03 AM, Erick T. Barkhuis wrote:
>> Arno Welzel:
>>
>>> 1967-09-12 for the 9. September of 1967
>>> BTW: This is why ISO 8601 had been invented
>>
>> If that's the case, I don't like ISO 8601.
>
> Why not, Erick? It's a good format which sorts naturally.
But apparently, it wants date formats to be three days off!
It might sort naturally, but it's not accurate enough.
--
Erick]]>Erick T. Barkhuis2014-06-22T14:24:12-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186268&th=123544#msg_186268
> Jerry Stuckle:
>
>> On 6/22/2014 4:03 AM, Erick T. Barkhuis wrote:
>>> Arno Welzel:
>>>
>>>> 1967-09-12 for the 9. September of 1967
>>>> BTW: This is why ISO 8601 had been invented
>>>
>>> If that's the case, I don't like ISO 8601.
>>
>> Why not, Erick? It's a good format which sorts naturally.
>
> But apparently, it wants date formats to be three days off!
> It might sort naturally, but it's not accurate enough.
>
>
No, "9" is September. The full date is September 12th, 1967. The
difference in languages and punctuation is causing confusion.
--
==================
Remove the "x" from my email address
Jerry Stuckle jstucklex@attglobal.net
==================]]>Jerry Stuckle2014-06-22T14:32:09-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186269&th=123544#msg_186269
> On 6/22/2014 10:24 AM, Erick T. Barkhuis wrote:
>> Jerry Stuckle:
>>
>>> On 6/22/2014 4:03 AM, Erick T. Barkhuis wrote:
>>>> Arno Welzel:
>>>>
>>>> > 1967-09-12 for the 9. September of 1967
>>>> > BTW: This is why ISO 8601 had been invented
>>>>
>>>> If that's the case, I don't like ISO 8601.
>>>
>>> Why not, Erick? It's a good format which sorts naturally.
>>
>> But apparently, it wants date formats to be three days off!
>> It might sort naturally, but it's not accurate enough.
>>
>>
>
> No, "9" is September. The full date is September 12th, 1967. The
> difference in languages and punctuation is causing confusion.
Obviously!
Arno is german. In Germany, it's common to write a dot as abbreviation
for 'st', 'nd', 'rd' and 'th':
He would pronounce "9. September" as "der neunte September" (the ninth
of September).
[Now that I have to explain this, it ain't funny anymore: Arno wrote
1967-09-12 and claimed this to be equal to the ninth of September 1967.
That prompted me, since I sometimes like to see funny things where they
aren't, to claim that ISO 8601 is no good at all, if it defines date
formats three days off]
--
Erick]]>Erick T. Barkhuis2014-06-22T14:45:25-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186270&th=123544#msg_186270
> Arno Welzel:
>
>> 1967-09-12 for the 9. September of 1967
>> BTW: This is why ISO 8601 had been invented
>
> If that's the case, I don't like ISO 8601.
Of course it was just a typo and 1967-09-12 is for 12. September of 1967 ;-)
--
Arno Welzel http://arnowelzel.de http://de-rec-fahrrad.de http://fahrradzukunft.de]]>Arno Welzel2014-06-22T14:47:36-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186272&th=123544#msg_186272
>>> 1967-09-12 for the 9. September of 1967
>>> BTW: This is why ISO 8601 had been invented
>> If that's the case, I don't like ISO 8601.
> Why not, Erick? It's a good format which sorts naturally.
Read the numbers very, very carefully.]]>gordonb.q26od2014-06-22T15:00:16-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186273&th=123544#msg_186273
<erick.use-net@ardane.c.o.m> wrote in comp.databases.mysql:
>>>> 1967-09-12 for the 9. September of 1967
>
> But apparently, it wants date formats to be three days off!
:-)
Good one!!!
jue]]>Jrgen Exner2014-06-22T15:26:56-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186274&th=123544#msg_186274
> Erick T. Barkhuis, 2014-06-22 10:03:
>
>> Arno Welzel:
>>
>>> 1967-09-12 for the 9. September of 1967
>>> BTW: This is why ISO 8601 had been invented
>>
>> If that's the case, I don't like ISO 8601.
>
> Of course it was just a typo and 1967-09-12 is for 12. September of 1967 ;-)
But how are us humans supposed to know which comes first?
what if you see 1967-31-09?
if it read 1967-Sep-09 then there is no guessing is there?]]>Mr Oldies2014-06-22T17:55:49-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186275&th=123544#msg_186275
> richard, 2014-06-21 20:28:
>
>> On Sat, 21 Jun 2014 17:42:29 +0000 (UTC), Doug Miller wrote:
>>
>>> 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.
>>
>> The problem with sorting is, it treats any value given as a string, then
>> determines which has the lowest value in total.
>> 1
>> 2
>> 3
>> 10
>> 20
>> 30
>> 100
>> 200
>> 300
>
> That's why *thinking* about how to store information is important.
>
> Even if you don't like to use a date datatype you should store the date
> values in a way that they can be used for sorting - so year first, then
> month, then day and all with leading zeros:
>
> 2014-06-22 for the 22. June of 2014
> 1967-09-12 for the 9. September of 1967
>
> and so on.
>
> BTW: This is why ISO 8601 had been invented - see
> <http://en.wikipedia.org/wiki/ISO_8601>.
Doesn't matter anymore. I am using the numeric day system instead.
where $date=date(z).]]>Mr Oldies2014-06-22T18:05:40-00:00Re: Storing dates
http://fudforum.org/forum/index.phpindex.php?t=rview&goto=186276&th=123544#msg_186276
noreply@example.com> wrote
in comp.databases.mysql:
>>>> BTW: This is why ISO 8601 had been invented
>> Of course it was just a typo and 1967-09-12 is for 12. September of 1967 ;-)
>
> But how are us humans supposed to know which comes first?
Simple: because it is unambiguously defined in ISO 8601.
> what if you see 1967-31-09?
Then you are not seeing a valid date in ISO-8601 format.
> if it read 1967-Sep-09 then there is no guessing is there?
Yes there is, because in many languages "Sep" doesn't make any sense.
Furthermore obviously dates in that format cannot be sorted easily.