On Mon, May 9, 2016 at 7:00 PM, jungle Boogie
wrote:
> On 8 May 2016 at 23:13, Stephan Beal wrote:
> > On Mon, May 9, 2016 at 5:40 AM, Stephan Beal
> wrote:
> >
> >> That suggests that the script is not consistently telling sqlite which
> TZ
> >> to use in all calculations. i will take a look
On 8 May 2016 at 23:13, Stephan Beal wrote:
> On Mon, May 9, 2016 at 5:40 AM, Stephan Beal wrote:
>
>> That suggests that the script is not consistently telling sqlite which TZ
>> to use in all calculations. i will take a look at it as time
>>
>
> just fyi: i can now reproduce the problem on my
On Mon, May 9, 2016 at 5:40 AM, Stephan Beal wrote:
> That suggests that the script is not consistently telling sqlite which TZ
> to use in all calculations. i will take a look at it as time
>
just fyi: i can now reproduce the problem on my x64, where my days are
shifted 1 to the left. Not sure
That suggests that the script is not consistently telling sqlite which TZ
to use in all calculations. i will take a look at it as time allows.
Probably just need to be sure to consistently pass the final argument to
strftime().
- stephan
(Sent from a mobile device, possibly from bed. Please
On 8 May 2016 at 12:28, jungle Boogie wrote:
> I'll set the TZ on the pi to match and see what happens.
We're on to something!
pi time:
$ date
Sun May 8 12:29:54 PDT 2016
x86 time:
% date
Sun May 8 12:30:04 PDT 2016
They match with cal.sql now!
http://kopy.io/GbbDR
So no problem with
On 8 May 2016 at 02:04, Stephan Beal wrote:
> On Sun, May 8, 2016 at 10:53 AM, Stephan Beal
> wrote:
>
>> The system clock is correct on your x64 machine, i assume? (Even if it's
>> wrong, that doesn't explain the days being shifted left by 1.)
>>
>
> One idea comes to mind: perhaps it doesn't
On Sun, May 8, 2016 at 10:53 AM, Stephan Beal wrote:
> The system clock is correct on your x64 machine, i assume? (Even if it's
> wrong, that doesn't explain the days being shifted left by 1.)
>
One idea comes to mind: perhaps it doesn't consistently deal with timezones
everywhere, and you've
On Sun, May 8, 2016 at 2:14 AM, jungle Boogie
wrote:
> (8) is on Saturday, that's correct for 2016.
>
> (7) is on Friday and in fact, all the days are shifted once.
>
> Both of those are a bit difficult to follow here so this link has both:
> http://kopy.io/NLViy
>
> What would cause the same
Hi Stephan,
On 18 February 2016 at 13:55, Stephan Beal wrote:
> On Thu, Feb 18, 2016 at 10:42 PM, Stephan Beal
> wrote:
>
>> Here we go:
>>
>> http://fossil.wanderinghorse.net/download/cal.sql
>>
>
> sorry, one more: it was just updated with minor doc improvements and better
> syntax conformance
list<mailto:sqlite-users at mailinglists.sqlite.org>
Subject: Re: [sqlite] determining is-leap-year in sqlite
On Fri, Feb 19, 2016 at 1:53 AM, Stephan Beal wrote:
> It can now optionally mark the current date (but this feature slowed it
> down from 'instant' to 'just under
On Fri, Feb 19, 2016 at 3:03 AM, Quan Yong Zhai wrote:
> My SQLite cte exercise, the output looks like cal in Linux shell:
> ...
>
>February 2016
> Su Mo Tu We Th Fr Sa
> 1 2 3 4 5 6
> 7 8 9 10 11 12 13
> 14 15 16 17 18 19 20
> 21 22 23 24 25 26 27
> 28 29
>
LOL! i needed
On Fri, Feb 19, 2016 at 1:53 AM, Stephan Beal wrote:
> It can now optionally mark the current date (but this feature slowed it
> down from 'instant' to 'just under a second or so', possibly due to SQL
> inefficiencies on my part).
>
Trimming the list of years from 100 years to now +/-5 years
On Fri, Feb 19, 2016 at 12:36 AM, k wrote:
> On 18/02/2016 21:55, Stephan Beal wrote:
>
>>
>>> http://fossil.wanderinghorse.net/download/cal.sql
>>>
>>>
>> Excellent CTE query, thanks, but one question: the query uses
> group_concat() and the documentation says 'The order of the concatenated
>
On 18/02/2016 21:55, Stephan Beal wrote:
> On Thu, Feb 18, 2016 at 10:42 PM, Stephan Beal at public.gmane.org>
> wrote:
>
>> Here we go:
>>
>> http://fossil.wanderinghorse.net/download/cal.sql
>>
>
> sorry, one more: it was just updated with minor doc improvements and better
> syntax conformance
On Thu, Feb 18, 2016 at 10:42 PM, Stephan Beal
wrote:
> Here we go:
>
> http://fossil.wanderinghorse.net/download/cal.sql
>
sorry, one more: it was just updated with minor doc improvements and better
syntax conformance (i had used a lot of double-quotes simply out of recent
scripting habit).
On 2016/02/18 10:38 PM, Stephan Beal wrote:
> On Thu, Feb 18, 2016 at 9:16 PM, Stephan Beal
> wrote:
>
>> Okay, i've hit a small stump and i'm looking for a hint without giving it
>> away:
>>
>> January and February 2016:
>>
>> [stephan at host:~/tmp]$ sqlite3 < cal.sql
>>1 2
On Thu, Feb 18, 2016 at 10:22 PM, Stephan Beal
wrote:
> On Thu, Feb 18, 2016 at 10:19 PM, Richard Hipp wrote:
>
>> On 2/18/16, Stephan Beal wrote:
>> >
>> > Thanks again to all for the feedback and suggestions!
>> >
>>
>> After your talk, can we publish your calendar CTE as another example
>>
On 2016/02/18 10:16 PM, Stephan Beal wrote:
> On Thu, Feb 18, 2016 at 8:59 PM, R Smith wrote:
>
>> etc.
>> Nice job on the calendar and good luck with the presentation!
>
> Okay, i've hit a small stump and i'm looking for a hint without giving it
> away:
>
> January and February 2016:
>
>
On Thu, Feb 18, 2016 at 10:19 PM, Richard Hipp wrote:
> On 2/18/16, Stephan Beal wrote:
> >
> > Thanks again to all for the feedback and suggestions!
> >
>
> After your talk, can we publish your calendar CTE as another example
> in the SQLite documentation?
>
i would be humbled. No need to
On Thu, Feb 18, 2016 at 9:52 PM, Stephan Beal wrote:
> --
>> Feb 2016
>> 1 2 3 4 5 6 7
>> 8 9 10 11 12 13 14
>> 15 16 17 18 19 20 21
>> 22 23 24 25 26 27 28
>>
>> Thank you!!!
>>
>> Not half bad, if i may say so :).
>>
>
> Except that Feb. has 29 days this
On 2016/02/18 9:31 PM, Stephan Beal wrote:
>> The first CTE sets up some parameters in the first 3 fields used to draw
>> the graph - play with those parameters for fun.
>>
> i wouldn't even know what to do with them :/.
Change them of course! :) - to be specific, the first 3 values from the
On Thu, Feb 18, 2016 at 9:50 PM, Stephan Beal wrote:
> i could do with the \r, but CHAR(10) does indeed do the trick:
>
withOUT the \r...
>
> --
> Feb 2016
> 1 2 3 4 5 6 7
> 8 9 10 11 12 13 14
> 15 16 17 18 19 20 21
> 22 23 24 25 26 27 28
>
> Thank
On Thu, Feb 18, 2016 at 9:42 PM, R Smith wrote:
> Use the Mandelbrot set CTE for a cheat-sheet...
> CHAR(13)||CHAR(10)... etc.
Doh!
i could do with the \r, but CHAR(10) does indeed do the trick:
select str from strMonth
where year=2016 and monthNum in (1,2)
looks like...
[stephan at
On Thu, Feb 18, 2016 at 9:16 PM, Stephan Beal wrote:
> Okay, i've hit a small stump and i'm looking for a hint without giving it
> away:
>
> January and February 2016:
>
> [stephan at host:~/tmp]$ sqlite3 < cal.sql
> 1 2 3
> 4 5 6 7 8 9 10
> 11 12 13 14 15 16 17
> 18 19
Stephan,
> Yeah, i should have mentioned that i'm simplifying to the range of dates
> "sometime within my lifetime." Anything else is irrelevant for my
> presentation ;).
then, you only need to calculate ( year % 4 ). This gives you a window
from 1900-3-1 to 2100-2-28 (two complete centuries!).
On Thu, Feb 18, 2016 at 8:59 PM, R Smith wrote:
> etc.
> Nice job on the calendar and good luck with the presentation!
Okay, i've hit a small stump and i'm looking for a hint without giving it
away:
January and February 2016:
[stephan at host:~/tmp]$ sqlite3 < cal.sql
1 2 3
On 2016/02/18 8:34 PM, Stephan Beal wrote:
> Every calendar known to man sucks rocks in some regard or other, so
> i'm not gonna sweat it. This is just a demo, and i've got a few hours
> of budget left on it, so i'm working on this as the finale. (The
> Mandelbrot CTE will be first, just to
On Thu, Feb 18, 2016 at 7:53 PM, R Smith wrote:
> May I offer this CTE from the tutorials in SQLitespeed in case you have a
> Math library linked.
> (your math function names for cos(), sin() and degtorad() may differ):
> with graph(gWidth, aInc, gAngle, gCos, gCosA, gSin, gSinA) AS (
>
On 2016/02/18 7:46 PM, Stephan Beal wrote:
> Hi, all,
>
> i just found a useful trick i thought someone else might be able to use...
>
> As part of a presentation i'm preparing to introduce colleagues to CTEs,
> i'm attempting to build a calendar (with output similar to the Unix 'cal'
>
On Thu, Feb 18, 2016 at 7:27 PM, R Smith wrote:
>
>> While I won't spoil your calendar fun, I have to ask, why not simply use
> the functionality SQLite already has to know exactly which months has which
> days?
>
Good question: the presentation is specifically about CTEs and i want to
show
On Thu, Feb 18, 2016 at 6:59 PM, Eric Rubin-Smith wrote:
> >
> >
> > select 2, 28 + (CAST(strftime("%j", c.year||"-12-31") AS INTEGER) %
> 365)
> >
>
> Here you assume that all years have either 365 or 366 days. Would that it
> were so!
>
> Look at the year 1752 -- you may notice something
Hi, all,
i just found a useful trick i thought someone else might be able to use...
As part of a presentation i'm preparing to introduce colleagues to CTEs,
i'm attempting to build a calendar (with output similar to the Unix 'cal'
command). (Please no spoilers - let me figure it out!)
As part
> Excellent CTE query, thanks, but one question: the query uses
> group_concat() and the documentation says 'The order of the concatenated
> elements is arbitrary.'
To a primitive observer any sufficiently advanced technology appears to be
magic.
group_concat() does not concatenate items in
On 2/18/16, Stephan Beal wrote:
>
> Thanks again to all for the feedback and suggestions!
>
After your talk, can we publish your calendar CTE as another example
in the SQLite documentation?
--
D. Richard Hipp
drh at sqlite.org
On 2/18/16, R Smith wrote:
>
> Use the Mandelbrot set CTE for a cheat-sheet...
> CHAR(13)||CHAR(10)... etc.
>
Simpler: char(13,10). The char() function takes one *or more*
arguments and generates one character for each.
--
D. Richard Hipp
drh at sqlite.org
On 2/18/16, Eric Rubin-Smith wrote:
>>
>>
>> select 2, 28 + (CAST(strftime("%j", c.year||"-12-31") AS INTEGER) %
>> 365)
>>
>
> Here you assume that all years have either 365 or 366 days. Would that it
> were so!
>
> Look at the year 1752 -- you may notice something odd happened that
>
>
>
> select 2, 28 + (CAST(strftime("%j", c.year||"-12-31") AS INTEGER) % 365)
>
Here you assume that all years have either 365 or 366 days. Would that it
were so!
Look at the year 1752 -- you may notice something odd happened that
September. :-)
Eric
37 matches
Mail list logo
