When you have more experinece in programming in more languages, you’ll find that in a lot of modern languages an int is always 32 bit and a long is 64 bits

Once you gain some more experience you will realize that ‘a lot of’ is not good enough. Some languages do, some don’t. If you define a format, you don’t say ‘int’, you say something like “int32 in network byte order” (a.k.a. big endian).

Interesting that you were boldly claiming that experts use a dd-MM-yyyy format

Stop being willfully ignorant. I’ll repeat it once more: my claim is that you should store your dates as individual components, not as a the time since an epoch. I don’t care how those components are stored as long as it’s clearly specced.

Does your janky string format of “18-03-2024” suddenly has to become aware of the timezone

No, there is no timezone, and that is the entire point. In the majority of cases you just want to store the local date. The point is that a local date or time is not necessarily a fixed point in time. If I have drinks at 18:00 every Friday, that doesn’t change when we switch to or from DST, it’s still 18:00 in local time. I don’t need a timezone, I know what timezone I live in.

Now, in cases where timezones do matter, for example if you have a Zoom meeting with someone from another country, you can store as local time + timezone. But this is still very different from storing a Unix timestamp. This meeting will be at a specific time in a specific timezone, and the exact moment in time will adjust when changes are made to that timezone. Again, a Unix timestamp does not allow for this, as it’s always UTC.

I assure you that 1710720000 will translate to the same janky “18-03-2024” format you’re using every single time unless you deliberately mess with timezones in code

No, it doesn’t. You can’t convert it to any date unless you “mess with timezones”, because 1710720000 is a specific moment in time and you have to provide a timezone when converting it to a date. You are mistaking the fact that some systems implicitly use UTC when converting for some sort of of universal standard, because it’s not.

Run the following Swift code:

let d = Date(timeIntervalSince1970: 1710720000)
print(d.formatted(date: .complete, time: .omitted))

You’ll get a different date depending on your location.

If your code will break because someone has different OS settings than yours, you are writing bad code.

Yes, and your bad code will break simply because you are abusing a datatype for something beyond it’s intended use. If you want to store an absolute point in time, by all means use a Unix timestamp, but if you want to store a local time you should never use it because it’s not mean for that and it doesn’t encode the information needed to represent a local time.

Even this would be better than a string:

struct { int year byte month byte day }

Yes that’s fine. I’m not arguing that you should store it as a string, I’m arguing that you should store it as individual components, in whatever format, instead of seconds since the epoch. As long as the format is well specced it doesn’t really matter. Strings are used all the time for representing dates by the way. For example, ASN.1, which is used everywhere, stores dates and time as strings and it’s perfectly fine as the format is specified unambigiously.

Six bytes as opposed to 10

In what archaic system are int’s still 4 bytes? Int is 64-bits, or 8 bytes, on any modern machine. If I read your format on a 64-bit machine, it’ll break. Also is that int little or big endian? You code still breaks if you spec an int32 and you store your date on an x86 machine (little endian) and I read it on a big-endian machine. You know what’s not ambiguous ? “This time is stored as an ISO8601 string”.

You also don’t store dates in a string that you’ll have to parse later

Depends. If the format is clearly defined, then there’s no problem. Or could use a binary format. The point is that you store day/month/year separately, instead of a Unix timestamp.

And you understand that you could have a date in unix time and leave the time to be midnight, right?

No, you can’t.

First of all, midnight in what timezone? A timestamp is a specific instant in time, but dates are not, the specific moment that marks the beginning of a date depends on the timezone.

Say you store the date as midnight in your local timezone. Then your timezone changes, and all your stored dates are incorrect. And before you claim timezones rarely change, they change all the time. Even storing it as the date in UTC can cause problems.

You use timestamps for specific instances in time, but never for storing things that are in local time. Even if you think you are storing a specific instant it, time, you aren’t. Say you make an appointment in your agenda at 14:00 local time, you store this as a Unix timestamp. It’s a specific instant in time, right? No, it’s not. If the time zone changes so, for example, DST goes into effect at a different time, your appointment could suddenly be an hour off, because that appointment was not supposed to be at that instant in time, it was supposed to be at 14:00 in the local timezone, so if the timezone changes the absolute point in time of that appointment changes with it.

When you think about it storing a date with 6 bytes would take more space than using Unix time which would give both time and date in four bytes. Y2K38 is the real problem. Y2K was a problem with software written by poor devs that were trying to save disk space by actually using more disk space than needed.

This comes to mind:

You don’t store dates as Unix time. Unix timestamps indicate a specific point in time. Dates are not a specific point in time.

Without drilling down into what that means, the limit of that data storage type will be a count of 4,294,967,296.

A little nitpick: the count at that time will be 2,147,483,647. time_t is usually a signed integer.

I was looking for a new printer and I also wanted to print photos. Problem with inkjets is that you have to use them regularly or the ink dries out so that was no option either.

I eventually settled on a black and white laserprinter, which is cheap to buy and run (a new 3000 page toner is like €40) and a Canon Selphy CP1500 for photos, which uses dye sublimation so no issues with ink drying out. It only prints 15x10 photos which covers the majority of my needs, for anything larger I want to use a good photo printing service anyway.

You could also do what they do in the Android world, let the phone run like crap all the time, then it won’t need to slow down because it was slow from day one.

You are saying I have the choice between a shitty choice and a shitty choice that breaks.

Until you invent a better battery tech those are the only options we have. Let me know when you filed your patent.

Which is weird because I’m not in a city and live in a small town of less than 20k people

Not weird at all. It’s much easier to run fiber in a small town than in a large city. Cities are denser and more crowded. It’s also more crowded underground. In a city you might have to close streets, you need to be more careful when digging because of all the other stuff underground.

All that makes it cheaper and easier to install fiber in small towns or smaller, less dense cities.

Look, I get you hate apple and desperately want to find fault with everything they do. I agree they are a bunch of greedy bastards that try to squeeze as much money out of their customers as they can, but this just isn’t one of the ways they do it. In fact it’s the exact opposite: it ensures old devices remain usable for longer.

The fuckers sold us devices that worked perfectly for years until they sent firmware updates to slow them down

This slow-down only triggers after the device already had a brown-out. That is: it has to at least crash once due to a worn out battery.

“The brakes on my car worked fine for years and now they suddenly don’t work anymore”. Batteries are a consumable. They wear out. Phones were crashing due to it. They pushed an update that ensured the devices remained usable instead of crashing under load.

Could they have communicated it better? Yes. Was it the right solution from a technical point of view? Also yes.

It doesn’t get progressively slower over time, it’s either in degraded mode or it isn’t.

If you want to use a car analogy, it’s comparable to limp mode. When your car detects an engine problem it goes into limp mode in which you don’t have full performance but you can at least get home. You’d rather have your car not do this and risk damaging the engine, or would you prefer it to simply stop working and leave you stranded?

Batteries wear out, it’s an unfortunate property of our current battery tech. You can either let your phone get unstable (risking data loss), have it refuse to work at all, or let its run in reduced performance mode so it at least stays usable. Those are your options. Pick one.

You’d rather have a phone that randomly crashes?

Many hundreds? I checked an a replacement for my iPhone 13 Pro battery is $89.

Walk into Apple store, hand over phone, pick it up an hour later. Couldn’t be easier. Looking at prices, 3rd party repair services using non-original parts charge the same or more as Apple does.

That was not to get you to buy another phone, in fact the opposite. It was to keep your phone functional even though it had a worn out battery.

In phones there is this concept called a ‘race to idle’. Basically, you want your phone to do nothing, because doing nothing uses very little energy. So when you do something on your phone, the goal is to do it as quickly as possible so it can go back to doing nothing and save battery. Your phone will be in this low-power idle state 99.999% of the time. You still want your phone to be responsive though, when you click on something you want it to respond without delay. That means that when you tell it to do something it has to go from this low power state back to a high speed state.

Now, iOS is really aggressive in this, it ramps up the CPU speed really fast. As a result, the power draw of the CPU goes from almost nothing to a high power draw very quickly. This causes problems with old batteries. As a battery ages it not only loses capacity, but it also becomes slower to respond to changes in power draw. If the CPU needs a lot of power quickly and the battery can’t keep up you get a brownout (drop in voltage) and the phone basically crashes and reboots.

So what Apple has done is that when iOS detects this happening (i.e. a crash due to the battery being unable to keep up), it will ramp up the CPU a little slower. Or to use a car analogy: they don’t change the top speed, but are less aggressive on the gas so it takes a little longer to get to that top speed. If you replace the battery it goes back to the original behavior.

This is basically a good thing, the alternative is that your phone keeps crashing. Where they screwed up is that they failed to inform users of this.

In practice it means that the rich pay very little tax. It’s been an ongoing debate for years, and changes are being worked on to tax actual gains.

This is misleading. The 49.5% tax in the Netherlands is on income above €75,518. Billionaires rarely make the bulk of their money as income.

We don’t have a capital gains tax, instead there is a tax on capital that’s based on expected return on that capital. It’s about 1% on money in bank account and about 6% on stock and other investments.

There are other shithole countries other than the US.

If you need guns just to be safe, you by definition live in a shithole.

I don’t live in the US. I live in a rural area in Europe. It’s not at all a problem here. Probably only a problem in shithole countries like the US.

How are people living on farms supposed to defend themselves against robbers if they don’t own guns?

Why is this only a problem in the US? You don’t think other countries have farmers? Or maybe that problem only exists in your head.