| Time |
Nick |
Message |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:31 |
|
collum joined #evergreen |
| 08:25 |
|
mantis joined #evergreen |
| 08:42 |
|
rfrasur joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
|
mmorgan1 joined #evergreen |
| 08:49 |
|
mmorgan2 joined #evergreen |
| 08:55 |
|
collum joined #evergreen |
| 10:44 |
bshum |
https://linuxfoundation.org/linux30th/ |
| 10:46 |
berick |
w00t |
| 10:53 |
mmorgan |
@dessert 41 bshum's tux doll |
| 10:53 |
* pinesol |
grabs some birthday cake with lots of candles for bshum's tux doll |
| 10:53 |
bshum |
mmorgan++ # lol |
| 11:14 |
|
rfrasur joined #evergreen |
| 12:29 |
|
collum joined #evergreen |
| 12:41 |
|
cschroth joined #evergreen |
| 14:53 |
* mmorgan |
finds that on test systems built using berick's ansible script, checkouts where I would expect the due date in the db to be 2021-09-01 23:59:59+00 get instead 2021-09-02 03:59:59+00 |
| 14:53 |
mmorgan |
What am I missing? |
| 14:53 |
alynn26 |
mmorgan, time zones? |
| 14:54 |
mmorgan |
alynn26: That's what I was thinking, but not sure how to fix it. |
| 14:58 |
jeff |
how are you viewing the 2021-09-02 03:59:59+00 timestamp reported above? |
| 15:02 |
mmorgan |
jeff: in the database field action.circulation.due_date via phppgadmin |
| 15:03 |
jeff |
it sounds like your postgres client timezone might be set to UTC. if this were psql, I'd recommend SHOW TIMEZONE; and SELECT NOW(): to help confirm that. |
| 15:03 |
mmorgan |
circs from the seed data have the 23:59:59 timestamp that I would expect. |
| 15:06 |
mmorgan |
Ok, SHOW TIMEZONE gives me Etc/UTC |
| 15:08 |
mmorgan |
SELECT NOW() - 2021-08-25 19:07:30.341906+00 |
| 15:08 |
csharp_ |
@who created a test server from the FUTURE? |
| 15:08 |
pinesol |
jweston created a test server from the FUTURE. |
| 15:09 |
jeff |
postgresql clients show TIMESTAMP WITH TIME ZONE values in the "local" timezone, so if you set your client timezone. If you change your postgresql client timezone, a value ending in 03:59:59+00 will likely display as 23:59:59-04 |
| 15:09 |
* csharp_ |
swims in the deep waters of perl multi-dimensional arrays and hashes |
| 15:11 |
berick |
@ana multi dimensional arrays and hashes |
| 15:11 |
pinesol |
berick: Mundanely as horrid animalist |
| 15:11 |
jeff |
the sample data load scripts appear to use the postgresql client timezone, which would explain the 2021-09-01 23:59:59+00 value you noted for "circs from the seed data" |
| 15:11 |
rhamby_ |
multi-dimsensional lists and hashes aren't bad, just take deep breaths and go with the flow |
| 15:16 |
jeff |
mmorgan: I'm guessing the root of the issue is your virtual machine has a timezone of UTC. unless your plan is to have a multi-timezone system, i'd recommend setting your virtual machine's timezone to what you want before you install Evergreen. |
| 15:17 |
jeff |
(or, unless your intent is to have a UTC virtual machine, which is not an invalid goal, but there may be some rough edges. I don't recall offhand if we have specific guidance on that with regard to Evergreen. |
| 15:18 |
jeff |
jeffdavis may have something to add with regard to sharp edges when your Evergreen libraries span multiple time zones. |
| 15:18 |
mmorgan |
jeff: ok, thanks! will give that a try! No plans for a multi timezone system. |
| 15:18 |
mmorgan |
jeff++ |
| 15:24 |
jeff |
time zone can be set in... many places. postgresql.conf timezone= setting, per-database setting (ALTER DATABASE dbname SET timezone TO '...';), client environment veriable PGTZ, etc. I think you're likely to have timezone = 'localtime' in postgresql.conf |
| 15:40 |
jeffdavis |
We have timezone set to 'America/Vancouver' in postgresql.conf and are using that same timezone on all our servers. We also set the lib.timezone org unit setting in EG - America/Vancouver for our root OU, overridden as appropriate for our libraries in other timezones. |
| 15:40 |
jeffdavis |
IIRC there are still a few outstanding timezone bugs but the above setup avoids the biggest headaches. |
| 15:49 |
jeff |
jeffdavis++ |
| 15:54 |
mmorgan |
Woo! 23:59:59! |
| 15:58 |
mmorgan |
So postgres.conf had etc/UTC as did the server. Set the server tz to America/New_York, and postgres.conf to 'localtime', restarted everything and now I'm seeing the timestamp I expect. |
| 15:58 |
mmorgan |
jeffdavis++ |
| 15:58 |
jeffdavis |
yay! |
| 15:58 |
jeffdavis |
jeff++ |
| 15:59 |
alynn26 |
yay |
| 16:00 |
mmorgan |
Now I have to remember what I was doing before falling down the rabbit hole :-/ |
| 16:10 |
* mmorgan |
is not the only one having timezone issues. Google workspace status alert estimates their next status update would be Jan 1, 1970 12:00:00 AM (UTC) ;-) |
| 16:10 |
alynn26 |
lol |
| 16:12 |
jeffdavis |
epoch fail |
| 16:12 |
* mmorgan |
groans, but |
| 16:12 |
mmorgan |
jeffdavis++ |
| 16:14 |
berick |
heh |
| 16:21 |
JBoyer |
jeffdavis++ |
| 16:37 |
jeff |
jeffdavis++ (and... *groan*) |
| 16:39 |
devted |
A DB patch upgrade question for ya'all. When upgrading a couple servers, we ran 3.4.3-3.5.0-upgrade-db.sql, 3.5.0-3.5.1-upgrade-db.sql, and 3.5.1-3.6.0-upgrade-db.sql. |
| 16:39 |
devted |
But to apply patches 1236, 1238, 1239, there are two provided options, either 3.4.4-3.4.5-upgrade-db.sql or 3.5.1-3.5.2-upgrade-db.sql. |
| 16:41 |
jeff |
not looking at the specifics, and just applying general version-upgrade advice: |
| 16:42 |
jeff |
once you've run 3.4.3-3.5.0-upgrade-db.sql you're done running any upgrade scripts that begin with 3.4 |
| 16:42 |
jeff |
3.4.3-3.5.0-upgrade-db.sql brings you to 3.5.0 |
| 16:44 |
jeff |
oh, i see what you're asking. |
| 16:45 |
jeff |
you've run 3.5.1-3.6.0-upgrade-db.sql and now you're at 3.6.0, but you're wondering if you need (1236, 1238, 1239) which aren't in any 3.6.0 upgrade scripts? |
| 16:46 |
devted |
yep! I saw the patches in the 3.4.4-3.4.5-upgrade-db.sql and 3.5.1-3.5.2-upgrade-db.sql files, but I didn't run either of those |
| 16:50 |
jeff |
bug 1599634 |
| 16:50 |
pinesol |
Launchpad bug 1599634 in Evergreen "Circulation report source to include in-house(non cat), and non cat circ" [Wishlist,Fix released] https://launchpad.net/bugs/1599634 |
| 16:51 |
jeff |
bug 1788260 |
| 16:51 |
pinesol |
Launchpad bug 1788260 in Evergreen 3.4 "reporter: action.all_circulations_combined_types should break out non-cat in-house-use " [Medium,Fix released] https://launchpad.net/bugs/1788260 |
| 16:55 |
Bmagic |
and this one? bug 1882825 |
| 16:55 |
pinesol |
Launchpad bug 1882825 in Evergreen 3.4 "Booking : Pull List - cannot save grid settings" [Medium,Fix released] https://launchpad.net/bugs/1882825 |
| 16:56 |
jeff |
bug 1835127 |
| 16:56 |
pinesol |
Launchpad bug 1835127 in Evergreen "Booking reservations should not require global permissions" [Medium,Fix released] https://launchpad.net/bugs/1835127 |
| 17:00 |
jeff |
and bug 1882825 |
| 17:00 |
pinesol |
Launchpad bug 1882825 in Evergreen 3.4 "Booking : Pull List - cannot save grid settings" [Medium,Fix released] https://launchpad.net/bugs/1882825 |
| 17:03 |
|
mmorgan left #evergreen |
| 18:02 |
pinesol |
News from qatests: Failed Log Output: osrfsys.log <http://testing.evergreen-ils.org/~live//archive/2021-08/2021-08-25_16:00:05/test.79.html> |
