lucifer: My listens cover art has gone weird. Sometimes the correct compilation cover, sometimes no cover, and sometimes the cover from another album the recording is from (but a rollover always displays the correct compilation title :S )
mayhem: almost December, we should probably finalize and start work on the Year in Music.
mayhem
yep. I guess I should start a YIM 2022 document.
chirayu999 joined the channel
chirayu999 has quit
loujine has quit
loujine joined the channel
lucifer
mayhem, alastairp: about local timestamps in listens, we decided to add a new column for storing the offset of the user's timezone at that time for each listen. (https://chatlogs.metabrainz.org/libera/metabrai...)
however, there are 2 issues.
1) we have timezones like UTC+7, UTC+8 in LB time zone options. these don't automatically change with DST. when DST changes, the user would have to automatically update their time zone in LB for the changes to take place.
mayhem
oh. how did we miss this?
(rhetorical question)
lucifer
However, we also have timezones like Europe/London etc which automatically update with DSTs.
so a simple solution would be to ban timezone of the first type or add strong warnings against using those.
alastairp
yeah, that seems like a mistake to have the user preference store an offset
do you know if there was a reason for it?
lucifer
we currently don't store an offset but the timezone name directly?
> we decided to add a new column for storing the offset of the user's timezone at that time for each listen.
what do you plan to store here. the tz name, or the offset?
lucifer
that was going to by next question. i think we wanted to go with offset value.
alastairp
because if we compute and store the hour offset based on timezone name in python at submission time, then we can update the python tzdb package when necessary
lucifer
i see makes sense
alastairp
although if we do that then we won't be able to show the timezone name (e.g. EST/EDT) with the timestamp when we show it in LB
lucifer
i am still wondering if we should allow users to submit a local timestamp directly as well
yeah :/
alastairp
wondering in which way? allow it, or deny it?
lucifer
allow it
alastairp
I still think that's a good idea (I believe we've discussed it before?)
lucifer
initially yes but not in the latest discussion.
alastairp
note that both RFC3339 and ISO8601 don't allow a timezone name as a specifier, only an hour offset: https://ijmacd.github.io/rfc3339-iso8601/ (at least from my reading of this)
ah, I see
it's possible that with a timestamp in UTC (or time+offset) + a user preference with a timezone, we'd be able to compute the name of the timezone based on knowing when it was
lucifer
right if the user is directly submitting a timestamp then the offset would suffice, assuming their player/device is upto date with timezone changes.
alastairp
however this wouldn't work if the user was in a different timezone than their current preference when they submitted it (I'm not sure this is a huge problem though... sounds like it might be inventing more problems for something that doesn't happen often)
lucifer
yeah true. someone will eventually complain about that but not a deal breaker for most.
alastairp
if they submit the offset then that still doesn't allow us to name the tz in terms of PDT/PST/ECT/ etc
lucifer
right
yvanzo
O’Moin
lucifer
i guess there could be another field for timezone but uh.
alastairp
yeah right, I'm not entirely convinced that this type of representation is necessary
yvanzo: a question about SEC updates, the comment on a ticket says that if you either dismiss the alert in github or create a ticket in the affected project and link to the SEC ticket that this will cause the ticket to close
but if I directly fix the issue without first making a ticket, will github close the SEC ticket? (I already see that in the dependabot security list on github the ticket has recently been closed due to my push)
yvanzo
reosarevok: about yesterday’s support request, I’ve just entered their email as verified directly in the database, but have you already dealt with verification email not arriving (apparently not even in spam folder) before? Any clue of possible causes?
alastairp
never mind, it just took github a while to close the ticket on jira. everything looks fine now
reosarevok
yvanzo: I have seen it a couple times, their mail provider might just eat it fully, not sure about the causes tho
yvanzo
alastairp: good to know, I thought it wouldn’t
alastairp: it sometimes happens the webhooks in charge of updating the ticket fails instead
lucifer
alastairp: i guess we could store both local timestamp and time zone? and both being optional.
alastairp
lucifer: in postgres? I guess there's no such thing as a "local timestamp", so it'd need to be timestamp, offset, and timezone (the timezone used to compute the offset, either the user preference, or a value passed by the client) as 3 different values
lucifer
right that's what i meant. the existing listened_at, local_listened_at, time zone.
alastairp
right. and what data type did you want local_listened_at to be?
lucifer
timestamp with time zone. i know PG would discard the timezone there.
yvanzo
reosarevok: thanks, replied about it.
alastairp
my current intuition is that an offset is much more useful than a timezone. I guess in terms of being able to convert and show a local time
AT TIME ZONE with a timezone name would work in SQL too, but it suffers from the problem of an out-of-date time db like you mentioned
lucifer
pg and python would easily apply the offset to the timestamp value so i think its equivalent
right i guess we'd have to do it in python. which we update frequently enough
alastairp
just to confirm about the out of date timezone db, can we pull a new minor version of the postgres image that we use and have an updated tzdb?
lucifer
yes should work i think
alastairp
because as long as we stay on a recent enough major version of pg that allows us to do this regularly then maybe that will work
lucifer
yup makes sense
going back to square 1, i think what we want is a way to specify a global time zone for all listens and optionally a way to override it one the listen level.
optionally because as discussed last time not sure if this some thing many users would want.
alastairp
I'm thinking of one of the blog posts about time/calendar which says something like "use concepts for future tasks [i.e. an event in London on the 2nd of Feb next year] but turn it into something concrete when it happens"
so for me I'm not sure if a timezone name is "concrete" enough, or an hour offset is better
yes, agreed that it should be optional at the listen level
I think that we should also bring in aerozol and monkey to discuss if they have any ideas about how we should display historical dates to users
lucifer
i think timezones are concrete enough because they'd account for DST and are convertible to offsets at will.
alastairp
if we want to just show "the local time at the time the listen was submitted" then an offset might be OK
I have a niggling feeling that there are some timezones which aren't historical