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

Groups > comp.databases > #513 > unrolled thread

Re: Storing dates

Back to article view | Back to comp.databases

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-22 14:59 +0200
    Re: Storing dates Jerry Stuckle <jstucklex@attglobal.net> - 2014-06-22 09:27 -0400
      Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-22 22:20 +0200
      Re: Storing dates Jasen Betts <jasen@xnet.co.nz> - 2014-06-23 06:01 +0000
    Re: Storing dates Tim Streater <timstreater@greenbee.net> - 2014-06-22 16:11 +0100
      Re: Storing dates Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-22 22:42 +0200

#513 — Re: Storing dates

[F'up2 comp.databases]

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.

<http://www.sqlite.org/faq.html#q16>


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] | [next] | [standalone]

#514

On 6/22/2014 8:59 AM, Thomas 'PointedEars' Lahn wrote:
> [F'up2 comp.databases]
> 
> 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.
>

Please take your political correctness and stuff it where the sun
doesn't shine.

You expect Jürgen to change his name just to suit you?  How about the
billions of other people in the world who have non-ASCII characters in
their names?

How like a troll.

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

And now you're bitching because Tim's attribution doesn't meet YOUR
standards.

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

No, because it does exactly what he needs it to do in this case.

>> 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.
> 
> <http://www.sqlite.org/faq.html#q16>
> 
> 
> PointedEars
> 

So?  The casting works.  What's your bitch.

Oh - I forgot.  The only time you can post something technical is if
someone has already posted it in that thread.  So you have to find
things which don't fit *YOUR* standards.

No wonder you're known as a troll in so many newsgroups.  You never have
contributed anything original and useful to any newsgroup.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#517

Jerry Stuckle wrote:

> On 6/22/2014 8:59 AM, Thomas 'PointedEars' Lahn wrote:
>> [F'up2 comp.databases]
>> 
>> 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.
> 
> Please take your political correctness and stuff it where the sun
> doesn't shine.
> 
> You expect Jürgen to change his name just to suit you?

No, I you had read more carefully, you would have found out that I expect 
him (and everyone else, including me) to conform to Internet/Usenet 
standards, so that his/their postings would not cause problems with 
conforming software.  Communication does not work without such a basic set 
of rules that all involved adhere to.

He can either use a replacement for the non-ASCII character in his name (he 
could keep is name of course, he could just not use it verbatim in his From 
header field values), he can use conforming software himself which would 
properly MIME-encode that character, or he can use error-correcting software 
on top of his software, like Morver.  As it is, he is doing neither, which 
is bad for everyone.

This problem is not limited to the “From” header field value, where his 
postings could be filtered out because of that (spammers and trolls often 
use non-conforming header field values, too).  It also applies to the 
“Subject” header field in which case his posting could break threads because 
the “Subject” is unwillingly mutilated when replying.

> How about the billions of other people in the world who have non-ASCII
> characters in their names?

They should be and many are smart enough to use conforming or error-
correcting software, or transcription where that is not feasible.  In fact, 
many netizens from Asia have adopted an English-sounding alias or would 
transcribe their names using the Latin alphabet in order to work around 
problems like this.
 
> How like a troll.

Pot, kettle, black.
 
>>> 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.
> 
> And now you're bitching because Tim's attribution doesn't meet YOUR
> standards.

Good readability of discussions is not a standard that *I* have set, and I 
am not bitching about anything.  I am commenting on *Jürgen’s* attribution 
line (obviously not Tim’s).
 
>>>> 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.
> 
> No, because it does exactly what he needs it to do in this case.

You do not know the case.  He has only named two examples of values, and for 
what we know, he has only *assumed* that it “works just fine”.  Has he 
checked each resulting value?  I doubt it.
 
>>> 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.
>> 
>> <http://www.sqlite.org/faq.html#q16>
> 
> So?  The casting works.

No, it does not.

> What's your bitch.

Your mode of language forms an empty intersection with mine.  What is a 
“bitch” in that context?  My valid *concern* is that the chosen approach at 
conversion for sorting is error-prone, and that, as a result, the records 
will be sorted wrong.  Read the FAQ.

A better approach is to add a column of the REAL or NUMERIC affinity and 
update it with the value of that column of the TEXT affinity.  SQLite 
supports the concept of type affinity, so that approach works.  BTDT.

<http://www.sqlite.org/datatype3.html>

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

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

#519

On 2014-06-22, Jerry Stuckle <jstucklex@attglobal.net> wrote:
> On 6/22/2014 8:59 AM, Thomas 'PointedEars' Lahn wrote:
>> [F'up2 comp.databases]
>> 
>> 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.
>>
>
> Please take your political correctness and stuff it where the sun
> doesn't shine.
>
> You expect Jürgen to change his name just to suit you?  How about the
> billions of other people in the world who have non-ASCII characters in
> their names?

 RFC-2047 is 17 years old, find some software that supports it,





-- 
umop apisdn


--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

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

#516

In article <2639518.R2M4nku0sZ@PointedEars.de>, Thomas 'PointedEars'
Lahn <PointedEars@web.de> wrote:

> [F'up2 comp.databases]
> 
> 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.

The attribution you quote here is in fact incomplete.

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

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

#518

Tim Streater wrote:

> Thomas 'PointedEars' Lahn wrote:
>> > 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.
> 
> The attribution you quote here is in fact incomplete.

Nonsense.  The only information that cannot reasonably be omitted is the 
name of the author of the precursor, so that the quoted text can be 
attributed to them.  Everything else is not essential, and is disturbing 
when included, for the discussion.  It can be retrieved by other means in 
the unlikely event that it is needed.

For example, the Message-ID of the precursor is the last Message-ID in a 
posting’s “References” header field value.  The “From” address often is not 
(and, for example, in my case, is certainly not) the preferred contact 
address because spammers can scan the “From” header field value more easily 
than the “Reply-To” header field.

That is why “<name> wrote:” is the factory setting for the attribution in 
several decent newsreaders.

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases

csiph-web