#metabrainz

/

      • mayhem
        what was your take alastairp ?
      • monkey
        Sure alastairp. Don't have a picture of it though
      • alastairp
        monkey: sent to whatsapp
      • monkey
        OK leave it to me
      • alastairp
        so there's a question of if we modify the incoming listen to add it?
      • where are TZ stored? in the listen json, or a col in the listens table?
      • mayhem
        user config table.
      • alastairp
        sorry, the timezone of a listen
      • mayhem
        that is the setting, but how does that get applied to the incoming data?
      • alastairp
        right
      • Mineo (I think?) pointed out that timestamp with timezone in postgres doesn't actually store the timezone of a datetime object
      • yuzie
        The previous idea is: if no local timestamp specified in submitted listen, then we use TZ in settings table
      • alastairp
        it just transforms it to the local server timezone correctly
      • lucifer
        i was thinking we should only apply that setting when we want to use the timezone info and a local timestamp wasn't submitted with the listen.
      • mayhem
        alastairp: that should be fine then, no?
      • lucifer: that makes sense. is choosing your timezone enough to express "when we want to use the timezone info"?
      • alastairp
        I think yes, once you choose a timezone we should apply it to the listens
      • BrainzGit
        [musicbrainz-server] 14reosarevok merged pull request #2632 (03master…MBS-12588): MBS-12588: Escape user-provided disc ID in regex https://github.com/metabrainz/musicbrainz-serve...
      • mayhem
        so, then all we really need to do is fix up the timezone before we submit data to PG and we're done?
      • (if the user set the timezone)
      • alastairp
        mayhem: when I looked into it, I think the recommendation was that if you want to store a time as local to the user then you need to store both the timestamp and the relevant timezone or offset as a separate data
      • lucifer
        mayhem: alastairp: not sure, thinking about how we want to handle cases like travelling or when someone moves to another timezone after some years.
      • yuzie
        yes, that makes sense, and then we don't need a column, but only apply the timezone when display to user?
      • alastairp
        lucifer: yeah, we thought about those, but also recognise that they're quite infrequent and not the common case
      • BrainzGit
        [musicbrainz-server] 14reosarevok merged pull request #2630 (03master…MBS-12585): MBS-12584 / MBS-12585: Block smart links: onerpm.link / withkoji.com https://github.com/metabrainz/musicbrainz-serve...
      • mayhem
        lucifer: but moving timezone when a user moves, doesn't require us to have a separate column, does it?
      • if the user needs to shift the listens between date A and date B, by X hours, we can adjust the timestamps.
      • lucifer
        mayhem, sorry not sure how the adjustment would happen. do you mean by the user changing the config?
      • mayhem
        no.
      • literally adding X hours to timestamp if it needs adjusting
      • lucifer
        i understand that part but where/what would do it? like would the ts writer do it the browser or something else?
      • alastairp: yup agreed, but we should decide if that's a use case we want to support.
      • alastairp
        lucifer: by altering timestamps/data at ingest stage, it means that once that change is done, all new items should be good (after you move, for example)
      • for temporary movements, one would hope that eventually clients start sending the timezone info
      • in which case, that timezone will apply even if the configurerd one is different
      • atj
        are you forgetting about DST?
      • mayhem
        the case I was thinking about was when a user says: Oh, I was on vacation for these 14 days.
      • Move all timestamps by 2 hours between date X and date Y
      • lucifer
        ah i see, mayhem so lettign the user select the listens they want to alter the timestmap for manually?
      • alastairp
        atj: we have a utc timestamp, and a name of a timezone, so I believe with that we can say "render this timestamp with the correct rules for the tz"
      • mayhem
        atj: I would love to forget about DST, but everytime I do, everyone gets angry that I am an hour late.
      • lucifer: yes
      • lucifer
        mayhem: yes that makes sense now 👍
      • mayhem
        cool
      • that said, we've not reached a conclusion: separate column or no?
      • lucifer
        alastairp: yes makes sense. the user changes the config when they move and then the future listens get the timestmap accordingly.
      • BrainzGit
        [musicbrainz-server] 14reosarevok merged pull request #2629 (03master…MBS-12586): MBS-12586: Adapt Brahms/IRCAM cleanup to new link style https://github.com/metabrainz/musicbrainz-serve...
      • mayhem
        2 minutes to close this topic.
      • atj
        alastairp: is the TZ set per listen or per user?
      • mayhem
        thoughts alastairp ?
      • alastairp
        mayhem: my understanding of the timestamp type is that modifying the time forward or back in this way will modify the underlying UTC value, which I don't think is what we want
      • lucifer
        i think separate column makes sense
      • i think separate column makes sense
      • alastairp
      • > When you insert a value into a timestamptz column, PostgreSQL converts the timestamptz value into a UTC value and stores the UTC value in the table
      • so I think a separate column makes sense
      • mayhem
        ok.
      • alastairp
        and it should be an offset, the realized value of the timezone at the time of the listen
      • mayhem
        is that a real PG column, or a value on the "data" JSONB?
      • alastairp
        so that it solves the DST issue, and the issue of DST dates changing
      • atj
        based on my limited understanding, separate column which is a FK to table of timezones
      • mayhem thinks the latter
      • lucifer
        alastairp: we can let the user select a custom timezone to be applied for a particular period of listens instead of actual +- hours.
      • alastairp
        lucifer: yep
      • my gut feel is that it's tied to listen time, and therefore should be an actual column
      • Freso
        <BANG>
      • It’s United Nations Monday for South-South Cooperation!
      • (I didn’t find an appropriate song, sorry. :\)
      • TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews, Per-project mb_db users (bitmap, reo), summit covid preparedness (alastairp, monkey)
      • mayhem
        alastairp: actual columns is serious work. :(
      • lucifer
        mayhem: we need to process the entire table for some tasks so we can do this at that time.
      • get the code and all ready but not deploy to prod just yet.
      • reosarevok
        mayhem, lucifer: shhh meeting time
      • :)
      • Freso
        No mailed in reviews! (I could have sworn I saw one earlier today, but I don’t see it now, so it was probably never there.)
      • (Also, main machine is still out of business, so sorry for being a bit slow. Current setup is a bit cumbersome to work with.)
      • Anyway…
      • reosarevok: Go!
      • reosarevok
        Hi!
      • I mostly worked on more React porting of small bits of the code such as cdstub and cdtoc templates
      • Freso
        (Others up: bitmap, zas, mayhem, monkey, alastairp, lucifer, akshaaatt, atj, CatQuest, skelly37, Pratha-Fish, Shubh, yellowhatpro, ansh, riksucks, yuzie, Freso — anyone else who would like to give review, let me know ASAP!)
      • reosarevok
        Also reviewed our TT macros and saw we could get rid of a surprising amount of them, which was nice
      • Still quite a bit to go, but a lot less :)
      • And small bugs and tickets here and there
      • Now helping bitmap test the React relationship editor, which is the next big bit of React coming, hopefully
      • Fin! CatQuest, go!
      • CatQuest told me that
      • "I'm healing and tired, will probably continue for a few weeks, been doing some editing (including cleaning that wikipedia-mess report)"
      • That'd be a list of issues in Wikipedia linkage the wikidata bot found, and I'm really happy CatQuest found some time to help with that :)
      • Freso: what about your week?
      • Freso
        🙋
      • I mostly (finished with?) recovered from surgery plus tried to bring my main rig back to life. My working conclusion right now is that it’s the motherboard that’s dead. :( I’ve ordered new parts which should hopefully arrive between Wednesday and Friday, so I should be back up and running then. Had a couple of days where I was feverish but for the last several days I’ve been off painkillers and I’ve started eating hot
      • and non-soft food now, and it seems fine, so I think
      • I have more or less recovered from the surgery… so that’s nice at least.
      • In between struggling with this, I did manage to give blog access to a number of our GSoC students and I have scheduled (the last?) two posts for Tues and Thurs this week. :)
      • I think that’s fin.
      • bitmap: Go!
      • bitmap
        hey
      • last week I fixed an issue causing missing CSS when deploying new containers, which I noticed when putting the new relationship editor branch on test.mb
      • (but css was missing on prod.mb for like 10 minutes while I debugged the issue and restored it...)
      • I also spent time testing/reviewing/updating open PRs, and fixed MBS-12566
      • BrainzBot
        MBS-12566: Incorrectly warn about bundled/shortened URLs in release editor
      • bitmap
        fin, go lucifer !
      • lucifer
        hi all!
      • last week, i worked on addressing feedback on existing PRs and finally merged almost a dozen of those.
      • thanks mayhem and alastairp for the reviews. further, i worked on verifying the canonical data fixes by running it over entire MLHD dataset which also led to wolf going down 😅
      • BrainzGit
        [musicbrainz-server] 14mwiencek merged pull request #2633 (03master…mbs-12589): MBS-12589: Return if direct search query times out https://github.com/metabrainz/musicbrainz-serve...
      • lucifer
        finally worked on moving messybrainz data to timescale db and debugging issues with api validation that were discovered as a result of the messybrainz PR.
      • alastairp: next?
      • alastairp
        hi
      • mayhem
        well done on the debugging and well done crashing a monster!
      • Freso
        (Still up: zas, mayhem, monkey, akshaaatt, atj, CatQuest, skelly37, Pratha-Fish, Shubh, yellowhatpro, ansh, riksucks, yuzie — anyone else who would like to give review, let me know ASAP!)
      • Pratha-Fish 👀
      • alastairp
        last week I reviewed some of lucifer's and ansh's PRs
      • I also did some work with Pratha-Fish to finalise his goals for the SoC project (extended until end of Oct), and worked with lucifer on testing his improvements to the canonical tables
      • I finished text dumps of the metadata and canonical tables, to be integrated periodically into lB dumps
      • I also worked on saving MB oauth keys in LB so that users can add MB tags directly from the metadata viewer
      • monkey and mayhem and I had a small talk about covid preparedness for the summit, which we'll discuss after the summit
      • Pratha-Fish: do you want to speak? I know you're busy with exams this week...
      • Pratha-Fish
        alastairp: sure
      • Hello everyone :)
      • lucifer
        alastairp: after the meeting? :)
      • alastairp
        lucifer: after reviews :(
      • Pratha-Fish
        last week I worked along with alastairp to figure out how to restructure the MLHD code base
      • lucifer
        :+!
      • Pratha-Fish
        and how to make it more "presentable" and usable for anyone new
      • Halfway done through the README file. Super happy to share that we'll be potentially writing a series of blogs explaining all the new and interesting findings that we made through the project :D
      • Currently busy with exams as well. But I'll be back on 14th 👌
      • alastairp
        not potentially, we will!
      • postive thinking
      • Pratha-Fish
        indeed! Super excited for the blogs 🔥
      • fin 🐡
      • riksucks: next?
      • Freso
        Or maybe… zas?
      • zas
        hey
      • Freso
        (Still up: mayhem, monkey, akshaaatt, atj, CatQuest, skelly37, Shubh, yellowhatpro, ansh, yuzie — anyone else who would like to give review, let me know ASAP!)
      • zas
        last week, I reviewed last PRs from skelly37
      • I also renewed few expiring certs (*.mb.o), did usual upgrades
      • rebooted wolf that was killed by lucifer ;)
      • mayhem snickers
      • plus usual supervision, patches, user support, Picard related stuff
      • TOPIC: MetaBrainz Community and Development channel | MusicBrainz non-development: #musicbrainz | BookBrainz: #bookbrainz | Channel is logged; see https://musicbrainz.org/doc/IRC for details | Agenda: Reviews, Per-project mb_db users (bitmap, reo), summit covid preparedness (alastairp, monkey), summit: extending main topic days to friday (mayhem, alastairp)
      • fin. mayhem ?
      • alastairp
        mayhem: ^ not sure if you think this is worth mentioning?
      • mayhem
        k
      • last week was catching up from the vacation and other emails. some convos that were already mentioned...
      • but, over the summer I worked out that QuickBooks' mail servers have been blacklisted by many providers.
      • so our invoices are going to spam. sigh.
      • you had one job.