Display timestamp in link embed (dynamic OpenGraph tags)

[omgfrost]

Hello,
As title says,
Whenever i copy the link generated by pasting message id, users have to open their browser to check it
Im asking if its possible for the link to instant timestamp embedded in discord channel
Thanks in advance

[vegeta897]

Hello, thanks for the suggestion, this is a great idea! I'll look into it. 👍

[vegeta897]

This will require SSR to deliver a dynamic OpenGraph tag, so the project will no longer be a static site but will include a server (which is fine by me).

Update: This actually doesn't require SSR, but it does require a server to modify the delivered html file to include the dynamic tag. I guess that's a form of SSR, but it does not involve rendering Svelte's output (this could be done, but it's not really necessary since we aren't making any API calls)

[omgfrost]

This will require SSR to deliver a dynamic OpenGraph tag, so the project will no longer be a static site but will include a server (which is fine by me).

Cool! Im running a small discord server,bit will be able to embed there?
I dont know anything about discord.js or .py.
Update: oh im sorry you meant you have to host this on your own server for dynamic stuff right?
Can you .

Cool! Im running a small discord server,bit will be able to embed there?
I dont know anything about discord.js or .py..

This will not require you to do anything on your end, assuming you want to continue using my site (at pixelatomy.com/snow-stamp). I just need to write an SSR version of Snow-Stamp and run a server for it instead of static hosting.

Perfect!
Sure,take your time.
Just let me know here when its enabled..thanks

[vegeta897]

Cool! Im running a small discord server,bit will be able to embed there?
I dont know anything about discord.js or .py..

This will not require you to do anything on your end, assuming you want to continue using my site (at pixelatomy.com/snow-stamp). I just need to write an SSR version of Snow-Stamp and run a server for it instead of static hosting.

[omgfrost]

Cool! Im running a small discord server,bit will be able to embed there?
I dont know anything about discord.js or .py..

This will not require you to do anything on your end, assuming you want to continue using my site (at pixelatomy.com/snow-stamp). I just need to write an SSR version of Snow-Stamp and run a server for it instead of static hosting.

Perfect!
Sure,take your time.
Just let me know here when its enabled..thanks

[vegeta897]

One issue I did not foresee is that the embed would have to display the timestamp for a specific time zone.

I considered just using UTC, and/or only showing the date without a time, since usually people use Snow-Stamp just to check the age of accounts or servers and don't need the exact time. But I think there's a better solution:

• We can include another URL parameter for time zone so that the shared link will always show the embed in that time zone
• The time zone name or code will be displayed in the embed for clarity
• Opening the link in your browser will ignore the time zone parameter and display the timestamp in the user's local time zone as usual, to avoid confusion
• We could include a drop-down box on the page that allows you to change time zone of the displayed output, as well as a checkbox next to the share button which controls whether the time zone is included in the link (a link with no time zone will embed as UTC). The drop-down box will default to the user's time zone and including the parameter in the link will be enabled by default.

[omgfrost]

One issue I did not foresee is that the embed would have to display the timestamp for a specific time zone.

I considered just using UTC, and/or only showing the date without a time, since usually people use Snow-Stamp just to check the age of accounts or servers and don't need the exact time. But I think there's a better solution:

• We can include another URL parameter for time zone so that the shared link will always show the embed in that time zone
• The time zone name or code will be displayed in the embed for clarity
• Opening the link in your browser will ignore the time zone parameter and display the timestamp in the user's local time zone as usual, to avoid confusion

I'm sorry i'm on IT but not on coding :D
I'd like to have them in CEST format
If it's included in what you have said even with a further parameter, i'm down with it!
Please do this fast (no forcing tho ❌ )
i'm so excited to see time zone directly in my channel!

[vegeta897]

I'm just documenting my thoughts and process, don't worry! I appreciate your input though. Including a parameter in the URL seems like the best solution.

On a related note, I'm trying to structure this in a way so that Snow-Stamp can continue to be hosted statically for anyone who wants that.

[omgfrost]

I'm just documenting my thoughts and process, don't worry! I appreciate your input though. Including a parameter in the URL seems like the best solution.

On a related note, I'm trying to structure this in a way so that Snow-Stamp can continue to be hosted statically for anyone who wants that.

let's do this! 👍

[vegeta897]

I made good progress today. The server works and is able to deliver a modified index.html containing the dynamic embed tag. Incoming wall of text:

Time zones

Working with time zones in JS is a real pain. I'm using the Day.js library on the server to display a timestamp in the specified time zone. It shouldn't be necessary to import this on the web side, which is good because I want to keep the bundle size low.

Currently, the time zone is added to the URL by its TZ database name (e.g. America/New_York). I couldn't just use a UTC offset number because that doesn't really equate to a time zone (different zones can share an offset, and also DST changes the offset). I also didn't want to use the short codes (like EST) because those are DST-specific and we're dealing with dates that could be during DST or not (and I don't want the URL time zone to change based on the snowflake).

There's also the issue of locale. The locale handles how time and date are formatted, such as Year/Month/Day ordering and 12/24 hour clocks. Snow-Stamp currently displays timestamps in the user's locale format automatically. I need to be able to tell the server to format the timestamp in the same locale. That means adding the locale to the URL too, unless it could be inferred from the time zone.

I may end up creating a custom list of shortened time zone names so that America/New_York becomes us-east or something. This list could also store the appropriate locale per time zone. The list would contain as many of the most common time zones as possible.

Another option?

I could potentially avoid all of this trouble by encoding the pre-formatted timestamp right into the URL. That way the user's browser can tell the server exactly how the timestamp should look in the embed. The only issue is I don't want to generate really long URLs. I could determine locale formatting in the browser and store it as a number with bitwise operations (I really only need YMD ordering and 12/24hr), and for the time zone name I could create a lookup table with as many names as possible that can then be converted to a single number. That number can be bit shifted into the locale format number and the result is a single URL parameter (in addition to the snowflake itself).

I think this is the better option overall.

That reminds me, I could compress the snowflake too, by using .toString(36). This would be optional, but it would turn the ~18 digit number into a ~12 character string. The only thing is that the snowflake would have to be split into 2 or more numbers, because JS can't convert numbers that big into strings without losing some precision.

[omgfrost]

ok i read everything, thanks for heads up, i didnt understand quite everything but i assume this is kinda diary for you.
All i can saybis: keep it up!
:D

[vegeta897]

I've abandoned the strategy of parsing YMD order and 12/24 hour formats because even if I could get that to work, I'd still need to apply it to a timestamp with the correct time zone. There are just too many unknowns involved.

So what I have now is a copy of the output locale string with a shortened time zone name appended.

(this change is not live yet, this is my test server)

The URL is longer than I'd like. For the above, the timestamp string is 8%2F26%2F2015%2C_2%3A56%3A49_PM_EDT.

I'm working on a compression algorithm that should significantly reduce the string length by taking advantage of the limited expected character set of a timestamp (e.g. 0123456789/-:., MPA). For strings that only contain these characters, we can expect something like ~50% reduction in length. My plan is to convert the string to a number (actually a set of numbers) and then represent those numbers in base64 (with a function like this). The parts that can't be encoded will remain literal characters and will be delimited in some way.

[vegeta897]

I know this is silly but I'm starting to reconsider using Day.js again. It only adds about 6kb to the bundle size and it could ensure consistent formatting across web/server with a much smaller footprint in the URL.

Update: The first problem is that Day.js only includes the en locale by default, but even if I included all locales in the bundle, there's no way to automatically (and reliably) switch to the appropriate one. I think it's better to avoid increasing bundle size and potentially screwing with the current reliable output (Date.toLocaleString) just for the sake of this embed feature.

However, I am okay with this less-reliable locale detection for the embed itself, and I can load all locales on the server with no problem. I came across someone's useful code for detecting browser locale and loading the corresponding Day.js locale.

For time zone, we have Intl.DateTimeFormat().resolvedOptions().timeZone which resolves to a string that Day.js can use. I think I might keep an array of all the time zones that Day.js works with. That would allow me to send only an index in the URL, and also ensure that the detected time zone is valid.

I should include some fallback behavior on both the web and server. If the web fails to detect a language, it won't be in the URL and the server will assume en. If the web doesn't provide a valid time zone, we will assume UTC.

[vegeta897]

After being held up for hours by a very annoying bug in Day.js, I've got this to a point where I am almost ready to merge to main.

I am strongly considering getting some tests written, because I now have many testable, pure functions that could use some thorough breaking in (and to protect against regression, of course). The only tough thing is that some of the functions depend on browser or environment values that I don't know how to recreate (because I don't know all the possibilities). I think this is okay though - I've designed the app so that the output of these functions should not break anything, but rather be ignored in favor of fallback values.

Another thing I should do (but I'm too lazy to do it now) is get more of my shared variables into the svelte store. I'm doing dumb things to get them to work across components.

I also have to make sure I know how to set up the server on my VPS, with nginx and whatnot.

Finally, I need to put in some due diligence and find people across the world to help me test this. I don't want to be blind-sided by time zone or locale issues.

I should probably create a pull request with a checklist for these things.

[omgfrost]

👍

[omgfrost]

@vegeta897 so how is it going? i cant wait anymore! xD

[vegeta897]

Changes merged, stand by for deployment...

🎉 Deployed! https://pixelatomy.com/snow-stamp
You may need to hard refresh (Ctrl+F5 in Windows) to get the updated version.