Evergreen ILS Website

IRC log for #evergreen, 2016-09-12

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

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

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat