Dealing with dates becomes much simpler conceptually when you realize that you are actually dealing with two different ideas masquerading as one: dates, and the actual instants in time which they name. Instants in time can only be unambiguously referenced by measuring some fixed unit of time intervals from some commonly agreed upon event (e.g. seconds since the Unix Epoch).
Dates are a mapping from human-readable labels to instants in time; critically, this mapping is not a total function (there are dates that map to no instant in time in a particular calendar, such as October 5-14 1582 in the Gregorian calendar, or 2:30am March 8 2026 in US timezones due to DST), nor is it in fact a function at all depending on how you define your inputs (1:30am November 1 2026 in US timezones is ambiguous if you don't specify DST/ST).
Furthermore, the mappings (both for past dates and future dates!) can themselves change over time (changes to DST, timezones, and calendars such as in TFA), and you need to keep track of these changes in perpetuity, as well as at which instant in time they were implemented, and we don't necessarily have that information for some of these historical changes, we only have the date as written down, which itself can suffer from the ambiguity problem (is it the date pre- or post- calendar change?).
This makes dealing with past dates tricky, and dealing with future dates speculative at best. For instance, what's February 28th + 1 day? The answer depends on the calendar system and the year; we can answer it definitively for past years but not necessarily for future years (maybe in 2040 we'll move the leap day to December 32nd). This is why it's important to immediately convert past dates (and sometimes future dates, depending on the use case) to unambiguous instants in time, and only convert them back to dates for display purposes.
"Wednesday, August 12th 2026" and "8 days from now" are also semantically distinct for some purposes: if have 8 doses of a daily prescription left, I'm still going to run out in 8 days even if tomorrow the government decides to repeal the Gregorian calendar, thus changing the name of "8 days from now" from "Wednesday, August 12th 2026" to "Sunday, August 2nd 2026". My medication doesn't care what the government decides to call 8 days from now, I'm going to run out either way. The pharmacy, on the other hand, very much does care what the government decides to call 8 days from now, because perhaps they're closed on Sundays. The calendar change means that "8 days from now" went from being not-a-Sunday to a Sunday, affecting their operating hours.
It's really just another instance of one of the two hard problems in computer science: naming things.
I get what you're saying, but if the government repealed the Gregorian calendar (and went back to Julian) that wouldn't change the day of the week. The day of the week is historically independent of the day of the month. Catholics and Protestants agreed on this in the calendar change. The original papal bull that set up the Gregorian calendar has Thursday 1582-10-04 followed by Friday 1582-10-15; Great Britain and colonies (if we're taking the US perspective) followed Wednesday 1752-09-02 with Thursday 1752-09-14.
Interesting, I didn't know that! I suppose I could edit my post accordingly, maybe a better example would be "the pharmacy won't let me get a refill until the date written on my prescription: Wednesday, August 12th 2026"? I think the point gets across regardless.
Docker has made this much much easier than it used to be, and the ease of publishing images has led to many SaaS companies providing "dockerized" versions of their services.
I write a lot of Terraform to manage internal infrastructure with dependencies on other internal and external infrastructure that's outside of my control. I define a module parameter for each dependency (usually with a default value that points to the real service URL) and then create a second module that uses Docker to spin up and configure local instances of each dependency and overrides the corresponding parameter.
This makes local testing very straightforward: `terraform -chdir=tests apply`
Sometimes you're using git in a context where you don't control the filenames, or where a potential attacker could influence or fully control them, at which point edge cases like this can easily turn into exploits.
I also chafe whenever I run into artificial restrictions on things like characters in names of things, because there's no good reason for them besides the laziness of developers or the limitations and inertia of existing systems that might be used under the hood, like DNS for instance.
I doubt you need an LLM for that, a diffusion model or perhaps even a deep CNN could probably do a passable job. You could train it by taking consecutive triplets of images [A, B, C] and providing [A, C] as inputs with B as the expected output.
My equally uninformed guess is that the presence of six empty boxes communicates that the code entered must be exactly six digits long in a way that a generic text input doesn't. It clearly delineates the digits which makes it easy to see how many you've entered and how many are empty, and the presence of an empty box suggests that it needs to be filled while a number that's simply shorter than the input field doesn't. At least, that's my steelman; maybe browsers should check if a field's min-length and max-length are the same and style them similarly?
So I don't have to spend 10-15 minutes saving all my open files (including the scratchpad ones I haven't named) and then later reopening all my applications, recreating all of my tmux windows and panes, setting up my vim splits and tabs again, and starting all of my stopped Docker containers?
I have a feeling someone is going to jump in with a "solution" to each of these forgetting that lots of work is ephemeral/transient and undeserving of even the slightest bit of automation or pre-configuration.
Interestingly, software engineers are usually considered exempt in the US, meaning they can be required to work more than 40 hours a week without overtime pay if employers choose to.
Unless you're imagining congress do something. I want to shoot fireballs from my fingers, but unfortunately we don't live in a world of magic.
Influencing Congress is wildly easier than shooting fireballs from your fingers. This is supposed to be a site with optimistic people that do things. Imagine what you could do politically with the help of LLMs.
If you think it's so doable, I welcome you to do it. I will be happy to say I am wrong if you pull it off. However, if congress has not even banned a seven day work week I don't see how they will reduce it to four because, of all job segments, tech workers want it.
Meanwhile I did some googling and I can buy a wrist-mounted flamethrower for $175, which is close enough to my fingers to make no difference.
You can lobby Congress to do things, even better you can volunteer at campaigns and try to elect people to Congress that want to do these things.
Acting like we are helpless and the future is determined is straight up loser talk while also not being historically accurate in the slightest.
You should go read about people starting wildcat strikes while working in literal company towns. There is tremendous power when we organize together, a power so great the elites have spent almost a 100 years trying to destroy the fruits of their success.
You, too, can do these things. I welcome you to. I will be happy to say I am wrong. Unions have real potential for creating change. I personally have no interest in joining a union for other reasons, but I am not opposed to them either.
But we weren't talking about unions. We were talking about congress. I think you will find that tech workers are not the only job segment, and far from the most sympathetic due to their wages. Lobbying for an extra day off will not get you far in the face of many more pressing issues, and the party most likely to stand up for workers is more interested in stopping data centers at the moment. Unless you're talking about a time horizon past which I don't think I'll be around to notice.
If only. The only way to delegate enforcement is to give them a monopoly on the legitimate use of violence. Unfortunately all such potential organizations are run by human beings, who, when given violence as a tool, will use that violence as a tool.
Dates are a mapping from human-readable labels to instants in time; critically, this mapping is not a total function (there are dates that map to no instant in time in a particular calendar, such as October 5-14 1582 in the Gregorian calendar, or 2:30am March 8 2026 in US timezones due to DST), nor is it in fact a function at all depending on how you define your inputs (1:30am November 1 2026 in US timezones is ambiguous if you don't specify DST/ST).
Furthermore, the mappings (both for past dates and future dates!) can themselves change over time (changes to DST, timezones, and calendars such as in TFA), and you need to keep track of these changes in perpetuity, as well as at which instant in time they were implemented, and we don't necessarily have that information for some of these historical changes, we only have the date as written down, which itself can suffer from the ambiguity problem (is it the date pre- or post- calendar change?).
This makes dealing with past dates tricky, and dealing with future dates speculative at best. For instance, what's February 28th + 1 day? The answer depends on the calendar system and the year; we can answer it definitively for past years but not necessarily for future years (maybe in 2040 we'll move the leap day to December 32nd). This is why it's important to immediately convert past dates (and sometimes future dates, depending on the use case) to unambiguous instants in time, and only convert them back to dates for display purposes.
"Wednesday, August 12th 2026" and "8 days from now" are also semantically distinct for some purposes: if have 8 doses of a daily prescription left, I'm still going to run out in 8 days even if tomorrow the government decides to repeal the Gregorian calendar, thus changing the name of "8 days from now" from "Wednesday, August 12th 2026" to "Sunday, August 2nd 2026". My medication doesn't care what the government decides to call 8 days from now, I'm going to run out either way. The pharmacy, on the other hand, very much does care what the government decides to call 8 days from now, because perhaps they're closed on Sundays. The calendar change means that "8 days from now" went from being not-a-Sunday to a Sunday, affecting their operating hours.
It's really just another instance of one of the two hard problems in computer science: naming things.