If you’re using an LLM to “learn”, stop. Otherwise, I don’t understand what lazy_static has to do with anything.

It’s hard to tell what you’re asking. But maybe you’re confused because println! (it’s a macro btw) expands to code that involves format_args! which is a compiler built-in that doesn’t take ownership of the token expressions that get passed to it. Notice how the bottom of the format_args! page has this to say:

Lifetime limitation

Except when no formatting arguments are used, the produced fmt::Arguments value borrows temporary values, which means it can only be used within the same expression and cannot be stored for later use. This is a known limitation, see #92698.

So, it’s kind of a feature and a limitation at the same time.

Ask yourself:

• Where do these stats come from?
• What do they actually measure?
• How can the total number of all Desktop Linux users or devices be known to anyone?

​
The fact of the matter is, none of these stats actually measure the number of users. Most of them are just totally flawed guestimates based on what is often limited web analytics data collected by them.

In fact, not even the developers of a single distribution can guess the number of people/devices using/running that specific distribution. A distribution like Debian for example has mirrors, and mirrors to some mirrors, and maybe even mirrors to some mirrors to some mirrors. So if Debian developers can’t possibly know the number of Debian users, do you think OP’s site knows the total number of Desktop Linux users?

And let’s not get into the fact that the limited data they collect itself is not even reliable. View desktop site on your Android phone’s browser. Congratulations! Now you’re a desktop Linux user. No special user-agent spoofing add-on needed. You’re even running X11. Good choice not following the Wayland fad too soon.

High or low, all Linux usage stats are fake.

Keep (Neo)Vim out of this.

As predicted, none of you got what I was referring to. Although simply doing the search would have got you there.

The EMBAG law stipulates that all public bodies must disclose the source code of software developed by or for them, unless precluded by third-party rights or security concerns.

Also as predicted, this escape hatchet exists for skipping compliance.

sublemmy

Lemmy communities. Mbin/kbin magazines.

Actually, I may have been too finicky about this myself.

Since I often write my own wrapping serialization code for use with non-serde formats, I didn’t realize that chrono::DateTime<chorono_tz::Tz> wasn’t serde-serializable, even with the serde feature enabled for both crates. That’s where the biggest problem probably lies.

In the example, using chorono_tz::Tz, and only converting to-be-serialized values to FixedOffset would probably put better focus on where the limitations/issues actually lie.

Like do you really not see this as something that shouldn’t be mentioned in a comparison between these crates? You must recognize the difference between what you’re doing and just plopping a Zoned in your struct, deriving Serialize and Deserialize, and then just letting the library do the right thing for you.

If that’s how it was framed in the comparison, it would have been fine. But my original objection was regarding the Local+FixedOffset example which, IMVHO, toys, if ever so slightly, with disingenuity (no offense or aggression intended, I’m a fan).

I think you also glossed over some of my other points. How do you write your serialization code using Chrono? Does it work with both chrono-tz and tzfile?

Something like this?

It can support tzfile too around the wire if it starts to expose tz names in a future version.

Why is the full presentation non-ephemerally stored instead of (timestamp, timezoe)?

Is the use-case strictly limited to checking the validity of a future date that was generated with assumptions based on current tzdata info? That’s valid, but quite niche I would argue.

And one can adjust the wrapper to have (timestamp, timezone, assumed_offset_at_ts). But yes, it can be argued that it’s not idiomatic/automatic/antecedently obvious anymore.

I think you misunderstood me.

What I meant is, someone who wants to serialize zoned dt info using chrono can basically send a timestamp and a timezone name on the wire, e.g. (1721599162, "America/New_York").

It’s not built-in support. It’s not a single human-readable string containing all the needed info that is being sent on the wire. But it does provide the needed info to get the correct results on the other side. And it’s the obvious solution to do, and it’s doable with trivial wrappers. No Local+FixedOffset usage required. And no wrong results inevitable.

That’s fine. I didn’t look at the code, but from what I gather, Jiff serializes the timezone name (not detailed tz info). chrono users would communicate the same thing, but it’s not built-in functionality in the dt type itself.

The example I referred to however may imply that chrono users would be inclined do the wrong thing, and get the wrong result as a sequence.

(humble personal opinion bit) It feels like it’s a case where the example was pushed a bit extra to fit into the “jump into the pit of success/despair” reference. A reference many, young and old, wouldn’t recognize, or otherwise wouldn’t care for anyway.

Yesterday I was browsing /r/programming

:tabclose

CTRL-F security
lol

From COMPARE.md:

Conversely, in Jiff, all time zone lookups by name are cached.

Is the cache invalidated if system tzdata is updated?

And what effect does the answer have on the example from “Jiff supports detecting time zone offset conflicts” if both zoned datetimes used the system timezone which got updated between 1. opening 2. parsing the two zoned datetimes.

Jiff losslessly roundtrips time zone aware datetimes

In this section, wouldn’t be more realistic for chrono users to use timezone info around the wire instead of on the wire, rather than using Local+FixedOffset?

I appreciate the attempt at comedy. But I have no problem with Alpine (other than the snail oldmalloc performance). I even contributed a port fix or two.

The more interesting part that should have been read from my comment was that Chimera DOES NOT use GCC. Not to mention that it ships non-GNU coreutils that are usable by desktop users. While Alpine has it’s GNU coreutils package overriding busybox because that’s what most users would want. So that’s another GNU component any non-meme non-turbo-minimalist desktop user would be using on Alpine.

Alpine uses GCC at least.

OpenBoozy/OpenBooza
BundleGreen

Hate to break it to you, but you’re not really learning.

Looks trivial and easy to automate.
I possibly would have done it if they had a test suite.
But unless I didn’t look hard enough, they have no tests at all (other than linting)!