Comment by FearNotDaniel
4 days ago
> Current time is determined by a Cloudflare Worker using the request IP
I was scratching my head for a while wondering why you need an IP address to determine the current time… I’m inferring this means geo-locating the IP to determine the client’s time zone and then using that to convert server time to the user’s local time, right?
Makes me think, it would be nice if there was a standard request header to specify preferred TZ for 'local time', just like Accept-Language (which sadly quite a few websites ignore and show me German-language content anyway just because my location is in a German-speaking country).
Still, great work OP :-) now can anyone tell me why Tintin is trending at the moment? Did I miss something? All my feeds seem to be suddenly full of Tintin content right now.
> “why Tintin is trending at the moment”
The Tintin character entered public domain in many countries in January 2025.
I think this “What a week” image is from a 1930 album (“The Crab with the Golden Claws”), so it’s part of the public domain now and can legally be used for things like this meme generator.
The situation in EU is different though. Hergé died in 1983, and I think his entire oeuvre has 75 years of protection after his death. I’m not 100% sure.
> The Tintin character entered public domain in many countries in January 2025.
Many countries or only US (which uses the publication date)? Considering that the original publication is in Belgium and that almost all countries use the author's death as the benchmark, I am not so sure (even with the rule of the shorter term).
Update: Wikipedia's copyright notes regarding a Tintin file... is definitely not what I've expected https://en.wikipedia.org/wiki/File:Tintin_and_Snowy_from_Tin...
> Also note that this image may not be in the public domain in the 9th Circuit if it was first published on or after July 1, 1909 in noncompliance with US formalities, unless the author is known to have died in 1954 or earlier (more than 70 years ago) or the work was created in 1904 or earlier (more than 120 years ago.)
And links to this footnote (https://guides.library.cornell.edu/copyright/publicdomain#Fo...):
> The differing dates is a product of the question of controversial Twin Books v. Walt Disney Co. decision by the 9th Circuit Court of Appeals in 1996. The question at issue is the copyright status of a work only published in a foreign language outside of the United States and without a copyright notice. It had long been assumed that failure to comply with U.S. formalities placed these works in the public domain in the United States and, as such, were subject to copyright restoration under URAA (see note 10). The court in Twin Books, however, concluded "publication without a copyright notice in a foreign country did not put the work in the public domain in the United States." According to the court, these foreign publications were in effect "unpublished" in the United States, and hence have the same copyright term as unpublished works. The decision has been harshly criticized in Nimmer on Copyright, the leading treatise on copyright, as being incompatible with previous decisions and the intent of Congress when it restored foreign copyrights. The Copyright Office as well ignores the Twin Books decision in its circular on restored copyrights. Nevertheless, the decision is currently applicable in all of the 9th Judicial Circuit (Alaska, Arizona, California, Hawaii, Idaho, Montana, Nevada, Oregon, Washington, and Guam and the Northern Mariana Islands), and it may apply in the rest of the country.
Also, Disney lost here (Accordingly, we reverse the summary judgment in favor of [Disney & co.]). It might not even PD in the US if this is upheld (and it seems so).
Being public domain decreases the liklihood that I will meme a given piece of IP
You could also compute the speech bubbles on the client's side...
Yes, but it seems
> No JavaScript is sent to the browser.
Is a design goal. I doubt it is possible without JS. Especially inside SVG.
Yes, that was a design goal!
It is probably technically possible to have the time continue to update with just CSS on the client (based on [1]), but the initial time still has to be set server-side.
[1] https://css-tricks.com/of-course-we-can-make-a-css-only-cloc...
4 replies →
(Thinking aloud) How I'd approach that:
- you could render the page using puppeteer server-side, getClientRect/calc and apply the dimensions to the path, then spit back the markup, OR
- you could use HTML + CSS to render the bubbles
3 replies →
...is it pedantic if I ask if WASM is considered JS and / or whether it can run without any assistance from JS?
I mean in the 2000s there were a number of other options (flash, silverlight, java, probably more) but that era is behind us, and that would be extra pedantic.
1 reply →
> Makes me think, it would be nice if there was a standard request header to specify preferred TZ for 'local time',
That's a another data point for fingerprinting, sadly. Not that Chrome would care, but Firefox and Safari teams do, I guess.
I believe this is already a thing? In JS at least
Firefox’s “resist fingerprinting” does a lot of things to stop fingerprinting. One of those things is that it fakes my time zone as being UTC. 99% of of the time I never notice this being an issue. But occasionally I’ll try to pull up the wordle late in the day and get tomorrows puzzle.
True. But pro-privacy is the argument that the server no longer needs to geo-lookup your IP address and find out where you are with much greater accuracy than is needed to determine what timezone you would like dates/times to be displayed in.
This argument holds as much water as saying that Google's Privacy sandbox reduces tracking because it gives advertisers the information they want. The IP is still available so you can assume that malicious websites will use it for whatever nefarious purposes they desire. An additional timezone header does not incentivize them to track you less.
well, for almost everyone this information is contained within the IP anyway, though.
In what sense is the user's local time zone "contained within" the IP? The only way I know to get from an IP address (i.e. those four eight-bit integers separated by period signs) to a client-side timezone is first to use a Geo IP lookup table to obtain a physical location (usually, but not always correct), and then use a timezone database to look up the current political timezone in that location. Sure, some server setups will automate this for you so that the already-looked up information is contained within the request object that your chosen language/framework supplies. Is there something I've missed about those four eight-bit integers somehow directly encoding information that specifies the user's timezone, or did you mean something different?
1 reply →
It’s available on the client side where most of the fingerprinting happens using JS.
And I feel like this is a lost cause at this point. Just assign every one of us a unique online ID and be done with it.
I’d appreciate if you didn’t try to bring everyone down with you, just because you have personally given up.
This recent HN submission is relevant.
https://news.ycombinator.com/item?id=43083151
It could be opt-out/opt-in and then all six users that care about privacy could do as they wished.
Sadly that almost makes things worse, if it's off then it's a data point that helps to id privacy conscious people.
2 replies →
I assumed something like this header already existed because it's such an obvious need, but...
> All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception.
according to [rfc2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3....). Presumably that makes a lot of awkward conversions unnecessary, but a separate TZ header would be a great addition.
Yeah that HTTP date format thing is kind of orthogonal - the same document slightly later explicitly says it's talking about the format used within HTTP messages/headers and not relevant to user-facing display within the page content. Which in that case makes a lot of sense because it's effectively saying "use UTC everywhere".
It could be a get parameter, with a picker allowing you to select your timezone.
That would be an absolutely awful user experience, unless there was also a way to default to knowing what the user's actual local timezone is without them having to manually pick it from a list of the 38 or so currently in use. I mean, you could try to persuade browser builders and site developers that this new get parameter is a standard that is automatically added to all requests by all browsers, and honoured if the site developers feel like it, but that's kind of messy and effectively doing the same job that request headers were designed to do.
You could have the user create an account which remembers which timezone they picked on signup.