<cil_z>
Beneroth, I try this: (by '((This) (list (: year) (: week))) group (collect 'id '+Agenda))
<cil_z>
it results in NIL
<Regenaxer>
done
<Regenaxer>
Does the collect by itself return something?
<cil_z>
this one works: (by '((This) (: week)) group (collect 'id '+Agenda))
<Regenaxer>
What is intended by grouping with 2 attributes?
<Regenaxer>
All with both equal?
<Regenaxer>
should work
<Regenaxer>
if 'list'ed (or better 'cons'ed to save space)
<cil_z>
sorry guys
<cil_z>
this one works: (by '((This) (list (: year) (: week))) group (collect 'id '+Agenda))
<cil_z>
tkx
<Regenaxer>
perfect :)
<Regenaxer>
'cons' would too
<beneroth>
T
<beneroth>
replace list with cons
<cil_z>
ok
<beneroth>
list -> last cdr cell is NIL
<beneroth>
cons -> use last cdr cell for last value
<Regenaxer>
phone again
<beneroth>
cil_z, what was wrong at first? I see no difference in the code you posted here?
<cil_z>
I think it was an issue with my database in REPL!
<cil_z>
I had to reload it
mtsd has quit [Ping timeout: 276 seconds]
<beneroth>
ah
<beneroth>
:)
<beneroth>
bbl, time for lunch
<cil_z>
bon appétit!
mtsd has joined #picolisp
<tankf33der>
Regenaxer: ping
<tankf33der>
afk.
lodsw has quit [Ping timeout: 245 seconds]
ubLIX has quit [Quit: ubLIX]
lodsw has joined #picolisp
mtsd has quit [Quit: Leaving]
<cil_z>
does "week" return an iso week?
<cil_z>
because I would expect (week ($dat "2019-12-31" "-")) to return "01" for an iso week instead of 53!
<Regenaxer>
Sorry tankf33der!
<Regenaxer>
I don't know what an iso week is. 'week' uses ts system here in Germany
<Regenaxer>
Something with Thursday ...
<Regenaxer>
Thursday is here (2020 1 2)
<Regenaxer>
: (week (date 2020 1 3))
<Regenaxer>
-> 1
<Regenaxer>
(ISO 8601, was: DIN 1355-1)
<cil_z>
iso week says that if the number of days of the last week of one year is >=4 then this week belongs to this year else it belongs to the new year
<Regenaxer>
In USA it seems to be different (Wikipedia). The first week is the one that holds first of January
<Regenaxer>
the week with the year's first Thursday in it
<cil_z>
yes I agree.
<cil_z>
(week ($dat "2020-01-02" "-")) gives 1 while (week ($dat "2019-12-31" "-")) gives 53. However those 2 days are in the same week!
<Regenaxer>
Thus they are not :)
<Regenaxer>
Not the same number
<Regenaxer>
btw, instead of ($dat "2019-12-31" "-"), (date 2019 12 31) is simpler and faster
<cil_z>
yes but according to iso 8601 this whole week should be numbered 1 instead of 53, isn't it?
<Regenaxer>
I think 53 is correct
<Regenaxer>
it is always relative to the year
<cil_z>
T, it was just to understand how things work under the hood ;-)
<Regenaxer>
In fact I don't remember when and why I wrote 'week'
orivej has joined #picolisp
<Regenaxer>
Maybe as this critical week 53 is at the end of the year when noone is working ("between the years") nobody cares ;)
<Regenaxer>
In one of my applications the users can schedule mailings on calendar week number. Nobody complained so far ...
freemint has joined #picolisp
<Regenaxer>
bbl
<cil_z>
anyway, it's not a big deal. As a way of learning pil, I'm rebuilding with it an app made previously with R... so I'm trying to get the same results...
<cil_z>
that was the reason of my question ;-)
<cil_z>
as an exercice I may write my own isoWeek function...
<Regenaxer>
ret
<Regenaxer>
Good :)
freemint has quit [Ping timeout: 240 seconds]
<beneroth>
week, year changes and daylight saving times are largely still an unsolved topic xD
<beneroth>
SAP used to crash on every daylight saving change (so twice a year) until few years ago
<cil_z>
;-)
<Regenaxer>
:D
<beneroth>
so whatever pil does is likely "according to modern industry standard and best practice" or better (as that doesn't exist)
<cil_z>
T
<beneroth>
a client of mine, with a huge internal ERP system, had his administrators get up in the night to restart the servers twice a year (not SAP, issue was caused by their internal programmers, not the system per se)
<beneroth>
I tried to explain their IT guys how timezone and daylight saving times work... but I failed. They preferred to continue with the established process...
<beneroth>
I even failed at getting across that using an ERP software which automatically converts all times to UTC+0 when saving to the database, mixed with custom database programming which always assumes local timezone, reads and stores date time values following this assumption, might be suboptimal...
<beneroth>
people prefer the stuff they know than alien scary concepts....
<beneroth>
"know" ^^
<Regenaxer>
right
<tankf33der>
Regenaxer: ping
<tankf33der>
fighting all day.
<tankf33der>
(format Lst) and (format (pack Lst)) works differently somehow.
<tankf33der>
(format (pack Lst)) *always* OK
<tankf33der>
(format Lst) sometimes returns NIL or cut tail of the list
<tankf33der>
Lst get from native.
<Regenaxer>
Hi tankf33der!
<Regenaxer>
oh
freemint has joined #picolisp
freemint has quit [Remote host closed the connection]
<tankf33der>
ha
freemint has joined #picolisp
<tankf33der>
i've tested without native
<tankf33der>
hm.
<Regenaxer>
(format 'sym) is the primary version
<tankf33der>
or not
<tankf33der>
checking again.
<Regenaxer>
Accepting a list is an additional convenienve
<Regenaxer>
should be the same though, as it packs internally