#thread archive timestamp
1 messages · Page 1 of 1 (latest)
hm, i do wonder how that comes to be
we get the creation timestamp from the ID the channel is made with on discords end
the archive timestamp is from the API
{
id: '927142702292828170',
guild_id: '222078108977594368',
parent_id: '824411059443204127',
owner_id: '83886770768314368',
type: 11,
name: 'thread archive timestamp',
last_message_id: '927145147370713098',
thread_metadata: [Object],
message_count: 7,
member_count: 3,
rate_limit_per_user: 0
}
```• d.js 13.4.0 • Type: `object` • time taken: `186.756752ms`
{
archived: false,
archive_timestamp: '2022-01-02T10:19:24.883000+00:00',
auto_archive_duration: 60,
locked: false
}
```• d.js 13.4.0 • Type: `object` • time taken: `146.436063ms`
2022-01-02T10:14:05.705Z
```• d.js 13.4.0 • Type: `object` • time taken: `0.141826ms`
that is indeed not exactly the creation timestamp, curious
well, seeing that it's the case with raw API data I don't really see how we could do it any different @toxic cargo
this is the timestamp from the snowflake of the channel id
I want to check if a thread has been archived before.
Where can i report this error in the docs?
ah, i know why
if you start a thread on a message it will share it's id with said message
since i started this thread on a message you sent :14 the thread's creation (via our lib) will be at :14
where it really was created at :19 hence the archive timestamp being that
Oh.
since this is the raw API data i don't see how we could get the true thread creation time 
yup, less of a discrepancy, but there is one nonetheless
@green raven you implemented* threads, right? any idea what's going on here?
only idea i have atm is that the snowflake is generated before the thread is, and archive_timestamp is set to now() rather than the snowflake by discord?
try it with a private thread, my guess is it should be identical then
since public threads send a message first
if one doesn't exist
I thought archive_timestamp wasn't supposed to be set on create though (null)
thought that too, yet there is even an info box on our docs that details it to be creation if the status never changed
private thread, still not quite
guess it utilizes a similar code path but just doesn't send the message
i think the conclusion is still "no can do" then
yeah, this is on discords end
@toxic cargo thanks, that's a curious one, but we can't do anything to help you with determining if a thread has been archived prior
the best i can think of is a magic number margin at which you assume it's the same
(though true thread creation in case it was started on a message is also not available)
(i might poke AJ to send it as null on create when Discord is back from break)
and maybe send the actual creation timestamp, while you're at it
because for "created on messages" threads that's really a bit yuck
...yeah
we're currently suggesting wrong information there for thread creation times
because it's really the messages creation
this isn't nullable in the docs but the description suggests it is 
because the archive status was never changed
I will try to see if they timestambs are always the same number geater then the other one.
presumably not, but i think a margin would make sense
though that's also not available if created on a message, because the message was obv. created way before
@green raven https://discord.js.org/#/docs/main/stable/class/ThreadChannel?scrollTo=createdAt and *Timestamp prob. need a disclaimer for that, don't you think?
that's inherited from channel
ah shit, so we can't even document that behaviour
its also documented wrong on the api docs
we can override jsdoc with virtual jsdoc for our docs
"If the channel is a thread channel created on a message this will reflect the creation of the message the thread was created on instead" moment
They arent.
sec, I can test doc things very fast
no need to hurry, but this is def. something we should somehow address
(and prob. something discord should look into as well, if they can. because ohboi is it confusing)
no idea why they didn't just send null to begin with...
- a timestamp that reflects when XYZ was last changed
- not null if never changed
like.. what even
at least we documented it as nullable, so IF they change we don't need to wait for a major release
"can be"? is that also not a guarantee?
well idk
You can create a thread with a starter message and not on a message.
if the message is old enough it sends a new one to create the thread on
o_O what
am aware, we get it from the snowflake
but discord doesn't send ANY timestamp either
yeah
yet they send the archived thing, which is something close to creation if it wasn't changed ever
which is still not the one they created the snowflake with
presumably because the snowflake creation is external code to the thread creation
and thread creation uses now() in some manner
snowflake generation happens in isolated processes I believe (how they get their guaranteed unique structure)
ye, that's what i meant to imply with "external code"
which also means that, once archive status has been changed once, there is no time to get the creation time
(even with that approximation)
yeah, so...technically we just shouldn't have created* on threads it seems 
that is what i'm starting to think
The only thing that we could maybe do is utilize the archive timestamp to fake created somehow, but that seems overly complex
or for discord to just send a timestamp instead of having us deconstruct snowflakes
- and then suddenly making a feature where that just doesn't hold true anymore

the more this situation unfolded the more i realized how scuffed threads are implementation wise, in regards to the previous API
also opened a window into the assumptions we base our lib on, because that's the only choice we have
- now if those assumptions don't hold true anymore... well.
well, AJ isn't on the API team, so this is client-first but cater to bot devs, kinda like timeouts...where we get no event on expiry so we're still tracking it manually
It's these little things that make you realize the teams don't collaborate as much as you would hope

anyways, i'm out
if you wanna bring this up in #archive-internal-lib-discussions do feel free (re: removal/documentation)
maybe something for v14 to consider, though i'm not sure how that works either, looking at the inheritance structure
unless "implements ChannelThatHasCreation" or some scuffed shit like that
I really want to redo channel hiearchy at some point, because thread channel really wants to inherit from guild channel....it just doesn't share most of its properties, I smell more interfaces and I don't like that

