| Time |
Nick |
Message |
| 05:51 |
|
wjr joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:09 |
|
JBoyer joined #evergreen |
| 07:20 |
|
rjackson_isl joined #evergreen |
| 07:23 |
|
agoben joined #evergreen |
| 08:30 |
|
kmlussier joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:48 |
|
bos20k joined #evergreen |
| 08:58 |
|
dkyle left #evergreen |
| 09:10 |
|
Dyrcona joined #evergreen |
| 09:16 |
|
tsbere joined #evergreen |
| 09:23 |
|
Dyrcona joined #evergreen |
| 09:27 |
|
yboston joined #evergreen |
| 09:39 |
|
maryj joined #evergreen |
| 09:56 |
* berick |
pings for laters |
| 09:57 |
tsbere |
That isn't a bad idea, though I wasn't offline for that long overall when I restarted my machine |
| 09:57 |
* tsbere |
is getting annoyed with his computer not letting barcode scanners work for some reason |
| 10:02 |
|
mmorgan1 joined #evergreen |
| 10:43 |
|
Dyrcona joined #evergreen |
| 11:00 |
|
mmorgan joined #evergreen |
| 11:40 |
* Dyrcona |
anticipates leaving the channel yet again. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:08 |
|
brahmina joined #evergreen |
| 12:11 |
dbs |
Dyrcona: ? |
| 12:11 |
dbs |
oh, just technical issues hopefully |
| 12:16 |
kmlussier |
Yes, it was just technical issues. |
| 12:16 |
* kmlussier |
is working from the same office as Dyrcona today and experienced the same technical issues. |
| 12:40 |
|
phasefx_ joined #evergreen |
| 12:40 |
Dyrcona |
Actually, doesn't look like I disconnected, really. |
| 12:53 |
|
maryj joined #evergreen |
| 13:03 |
mmorgan |
I just set up a loan duration of 48 hours and it behaves just like a 2 day duration, the item is due at midnight on the 14th. |
| 13:04 |
Dyrcona |
mmorgan: I would almost expect that. |
| 13:04 |
mmorgan |
I changed it to 47 hours, and it's due in 47 hours. |
| 13:05 |
mmorgan |
I changed it to 48:00:01 and I get 48 hours and 1 second. |
| 13:05 |
Dyrcona |
When it gets to the heart of the database, I believe it is just a number, so there's no difference between 48 hours and 2 days, AFAIK. |
| 13:07 |
mmorgan |
Looking in the database, my "48 hours" is stored as 48:00:00, "2 days" is stored as "2 days" |
| 13:07 |
* Dyrcona |
is probably wrong about the cause, then. Wouldn't be the first time. :) |
| 13:08 |
mmorgan |
I didn't see a Launchpad bug - has anyone else run across this? |
| 13:09 |
Dyrcona |
Actually, I still think it is probably a Postgres thing: select '48:00:00'::interval = '2 days'::interval; |
| 13:09 |
Dyrcona |
Returns 't' |
| 13:10 |
mmorgan |
Interesting. I'm using the duration 48:00:01 for now. Don't think anyone will notice the extra second. |
| 13:10 |
Dyrcona |
Not likely. |
| 13:12 |
mmorgan |
It's odd, though. There are other older rules for "24:00:00" and "72:00:00" which makes me think it was working at one time. |
| 13:12 |
dbwells |
mmorgan: There is a step in the checkout process that sets the due time to 23:59:59 for any circ with a day-granular interval. Our "24-hour" checkouts have an interval of 23:59:59 for that reason. |
| 13:13 |
mmorgan |
dbwells: Has that always been the case? |
| 13:13 |
dbwells |
At that point in the process, the interval has already been converted to seconds, so it doesn't know the difference. |
| 13:14 |
* Dyrcona |
looks at the light bulb turning on over his head... dbwells++ # for the memory jog. |
| 13:14 |
dbwells |
Probably not always, but for a very long time (likely pre-2.0 days). |
| 13:15 |
mmorgan |
So pretty much "always" from my perspective ;-) |
| 13:15 |
Dyrcona |
:) |
| 13:16 |
* Dyrcona |
wonders if Postgres has a decent way to tell the difference and look up some documentation. |
| 13:17 |
* mmorgan |
needs to adjust some hourly loan durations. |
| 13:19 |
mmorgan |
So, is this bugworthy? |
| 13:19 |
jeff |
the behavior was intentional at the time, but if you're seeing side effects that bear either further docs clarification or a different approach, perhaps. |
| 13:21 |
* mmorgan |
would expect "2 days" to behave differently than "24 hours", but that could be just me. |
| 13:21 |
|
jvwoolf1 joined #evergreen |
| 13:25 |
* mmorgan |
will open a launchpad bug for further docs clarification and possibly a different approach... |
| 13:25 |
mmorgan |
dbwells++ Dyrcona++ jeff++ |
| 13:25 |
jeff |
around that same time was the change that future-dated overdue fines. |
| 13:25 |
jeff |
(which dbwells has a branch to change that back) |
| 13:26 |
* mmorgan |
didn't realize that future dated fines was a change at one point. |
| 13:26 |
jeff |
i had memories of that time being a bad one, where we saw doubled overdue fines for circs that existed before the upgrade which included the change, but the last time i spent a few minutes looking for examples of that issue, i was unsuccessful. |
| 13:27 |
jeff |
future-dated fines are the current status quo, iirc. |
| 13:27 |
mmorgan |
jeff: Yes, that's true. |
| 13:27 |
* mmorgan |
thought it was always so. |
| 13:27 |
jeff |
daily overdue fines on circs with day-granular durations generated at (for example) 2 AM are future-dated to 23:59 |
| 13:28 |
Dyrcona |
Very little was always so. :) |
| 13:28 |
mmorgan |
:) |
| 13:29 |
Dyrcona |
All I've found about interval so far is that it is a 16-bit type. This means it is converted to an integer in the database. That does NOT mean that 48 hours and 2 days are the stored as the same integer. |
| 13:30 |
Dyrcona |
I may take up the quest again later. |
| 13:30 |
* mmorgan |
needs to run out for a bit... |
| 13:37 |
miker |
dbwells / mmorgan: re "always been that way", yes ... implicitly before hourly circ was supported, and then explicitly for day-granular intervals since then. |
| 13:39 |
miker |
jeff: the future-dating happened when hourly circ was first introduced, btw, to support it with simpler code IIRC |
| 13:39 |
* dbs |
seems to recall being an instigator at least for the 23:59:59 behaviour |
| 13:42 |
miker |
Dyrcona: re "48:00:00" vs "2 days", they are different when applied to timestamps that cross DST boundaries, but the same when comparing intervals. For that reason, we use and recommend the "days" (or "weeks", etc) variant for day-granular circ periods |
| 13:43 |
* Dyrcona |
still may look into the Postgres code to see how they're implemented, because curious.... |
| 13:46 |
|
krvmga joined #evergreen |
| 13:47 |
miker |
(not that the difference actually matters the way we use them, but it can matter when futzing with data directly) |
| 13:50 |
jeff |
miker: i remembered why, but looking at scroll i guess i didn't state that. :-) |
| 13:51 |
* Dyrcona |
never really looked at OpenSRF::Utils::inverval_to_seconds. I see how that works and why it can't tell the difference right now. |
| 13:51 |
* Dyrcona |
has a meeting... |
| 13:52 |
|
ssieb joined #evergreen |
| 13:52 |
miker |
jeff: I think tadl may have been one of the drivers for hourly? in any case, it was really for the room ... I've decided to dump as much history out of by brain as I can, when the opportunity arises ;) |
| 13:56 |
jeff |
no hourly here. we did drive some other things like rentals and hold capture verify, though. both of which we no longer use. :-) |
| 13:56 |
jeff |
(good lessons in today's "must have" is tomorrow's "we used to use/do that?") |
| 13:57 |
jeff |
i suppose I should s/ is / can be /, lest I claim that ALL features are so short lived. |
| 13:59 |
jeff |
miker++ history dumps |
| 14:09 |
|
kmlussier joined #evergreen |
| 14:12 |
|
krvmga joined #evergreen |
| 14:12 |
|
Dyrcona joined #evergreen |
| 14:19 |
JBoyer |
Does anyone remember a recent LP bug about the mobile view of a user's account? Items out specifically? The table is only about half-width and if there's a fix out there already I certainly don't need to re-do all of the poking and prodding. |
| 14:21 |
JBoyer |
LP has been / is in the process of being searched, but you know how that goes. |
| 14:23 |
JBoyer |
Huzzah! lp 1614807 |
| 14:23 |
pinesol_green |
Launchpad bug 1614807 in Evergreen "Inconsistent styles and responsive design issues in My Account grids" [Medium,Fix committed] https://launchpad.net/bugs/1614807 |
| 14:30 |
dbs |
Conifer was an hourly driver I think |
| 14:30 |
dbs |
lots of 4-hour reserve items etc |
| 14:31 |
kmlussier |
JBoyer: That interface needs a lot more work in the responsive design area. |
| 14:32 |
JBoyer |
kmlussier, I don't doubt it, it's a difficult interface to make work at that size, but being 50% of the screen width is REALLY unpleasant. :) |
| 14:33 |
JBoyer |
kmlussier++ # for working on it though |
| 14:34 |
* JBoyer |
would actually like to do an <input> audit sometime, autocapitalization and autocorrect don't get along well with username fields. :( ) |
| 14:43 |
|
bmills joined #evergreen |
| 14:44 |
|
bmills joined #evergreen |
| 14:45 |
|
rlefaive joined #evergreen |
| 15:03 |
dbs |
kmlussier++ |
| 15:03 |
dbs |
JBoyer__ |
| 15:03 |
dbs |
JBoyer++ # i mean! |
| 15:03 |
* dbs |
bumped join_collapse_limit up to 10 but is still seeing horribly slow bookbag response times, hrm |
| 15:07 |
|
collum joined #evergreen |
| 15:12 |
JBoyer |
Dyrcona, jeff, mmorgan, and miker: because I could not let it go I dug around in the PostgreSQL source until I could finally answer the question and no, there's no way to tell later how an interval was specified. Internally they're just months, days, and a remaining time offset. That's why seconds = 24 hours becomes 1 day. |
| 15:16 |
|
mmorgan1 joined #evergreen |
| 15:22 |
|
rlefaive joined #evergreen |
| 16:17 |
|
mmorgan joined #evergreen |
| 16:53 |
|
miker joined #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:17 |
|
jvwoolf1 left #evergreen |
| 17:18 |
* dbs |
bumps join_collapse_limit to 12 |
| 17:24 |
Bmagic |
oh jees, is this down? http://download.dojotoolkit.org ? |
| 17:25 |
jeff |
from earlier in #dojo (-0800 timestamps): |
| 17:25 |
jeff |
11:20:26 < jason0x43> I believe the physical servers are being moved. |
| 17:25 |
jeff |
11:33:00 < dylanks> Sorry, yes, that's the reason |
| 17:25 |
jeff |
11:33:32 < dylanks> It's a looooooong story |
| 17:31 |
dbwells |
dbs: You may have followed a trail to here already, but there is an open bug (with branch) specifically addressing bookbag speed after a recent upgrade, bug #1499086. The last comment there was some confusion about where/how the fix actually applies to bookbags, but maybe it applies to you. |
| 17:31 |
pinesol_green |
Launchpad bug 1499086 in Evergreen "Slowness/timeout on loading bookbags in OPAC" [Medium,Incomplete] https://launchpad.net/bugs/1499086 |
| 17:38 |
jeff |
Bmagic: if you're just trying to grab a copy of Dojo 1.3.3, you can probably get it with a reasonable degree of trust from here: https://github.com/dojo/dojo/releases/tag/1.3.3 |
| 17:39 |
jeff |
> tagged on May 13, 2013 · 2233 commits to master since this tag |
| 17:39 |
Bmagic |
right on! |
| 18:06 |
Bmagic |
has anyone encounted this when importing MARC for a PO: (from the server log) retrieve biblio.record_entry called with no ID... Which showed an error on the staff client of BIBLIO_RECORD_ENTRY_NO_FOUND |
| 22:19 |
|
ssieb joined #evergreen |
