How Old Can a File Be?

[@devdetour]

Check out Javascriptmas on Scrimba here: scrimba.com/javascriptmas?via=devdetour Thanks Scrimba for sponsoring this video!

[@Pawlo370]

6:52

[@Manny73211]

unix timestamps can be negative. The start of 1970 was arbitrarily chosen because they needed something to base the coordinates on, and 1 AD wouldn't work because they were using 32 bit integers.

[@pablodavidclavijo4609]

the cycle started at 1601 because they probably aligned them in such a way so a cycle would start at the year 1.

[@android-user]

This

[@mylittleparody2277]

But in computers, numbers start at 0 Using unsigned number instead of signed when you count seconds since a date would have been more useful. Or you know, using 64 bits from the start instead of 32. Or even a special date staing "unknown date" and an other "other format, check next bytes". That would have helped for the future of the past, meaning today.

[@stayfrost04]

@@mylittleparody2277 In computers they do, not in calendars though. There was no "Year 0". It went from 1BCE to 1CE and thus 400 year cycles would be taken from Year 1-401, 401-801, 801-1201, 1201-1601, 1601-2001. Since computers became prevalent in the last cycle and thus all their files would be created in that time era (1601-2001), they must've decided to use that as a starting point. This I think ignores the couple of days or so we skipped when switching to Gregorian so its meaningless when talking about objective continuation and for all intents and purposes, the start is just an arbitrary date that doesn't matter as long as its sufficiently far back enough.

[@griffonboi]

@@mylittleparody2277 Well, they couldn't use 64 bit from the start. Because 64 bit hardware didn't exist yet.

[@NotBroihon]

​@@stayfrost04that's just the tip of the iceberg though. If you take a look at eg. the astronomical calendar it includes year 0, so do various variants of ISO 8601. The best answer is to not think about time and timezones when it comes to computers.

[@captainvenom7252]

Before clicking on the video, I know that its gonna be so useless. That's why I clicked on the video. And, yeah, its pretty useless, and its worth it

[@cnce1]

As useful as Family Guy Compilation #211

[@MJGTMKME123_Official]

no it isn't you troll

[@VermeilChan]

That's why we clicked it 🗣️

[@redyau_]

Thank you. Now, on to watching!

[@reda29100]

Has anyone watched a game challenge? They do it cuz it's fun, not that they're restricted in game for any reason. Fun for us anyway

[@gungun974]

Tiny fun fact. For one of my job, I created a form where a user can register the birthday of a customer. One days my client has needed to create a new customer and my system refuses to create it. Believe what ! Some people born before 1970 are still with us so I can’t assume unix timestamps is a number always positive xD That’s was a one line fix but anyway, i was feeling a little stupid at this moment.

[@Barmem]

You can encounter more problems if you remember that time zones exist and for some reason the customer's birthday will shift a day here or there.

[@arturpaivads]

Unix timestamp should always be 64 bit signed.. Never assume that anything or anyone can't be older than 1970 hahaha.

[@ahscott2001]

(For legal reasons, this is a joke) So you're saying the solution is to eliminate all the people born before 1970.

[@gungun974]

@@arturpaivads yep but this project was in JavaScript so everything is already signed and this was really just a server validation issue. Just a strange oversight from me that 1970 was not really long ago.

[@gungun974]

@@Barmem if I correctly remember. Date were stored in timestamps in millisecond in UTC. But I agree, never store a DateTime thats not in UTC or without the timezone offset.

[@smaza2]

calling windows still the most popular desktop algorithm "for now" is exactly what a linux user would say

[@i_am_called_glitchy]

linux user here, confirmed.

[@maddox5081]

Cause once Microsoft ends up forcing shitty spyware on you, it goes downhill for Windows.

[@UltraGaivalas]

"the most popular desktop algorithm" is the phrase that only a luser would say

[@cewla3348]

@@maddox5081 people have been saying that "the spyware will kill windows this time" for decades

[@ketchup901]

@@maddox5081 You mean like they are already doing and have been doing for 15 years?

[@leamir0]

3:37 some microsoft employee about to have a bad day on 30/12/2107 when they remember that

[@MrBen41234]

Someone should compile a list of all upcoming Y2K events

[@KSPAtlas]

​@@MrBen41234There's a wikipedia article for it

[@toshibe2805]

@KSPAtlas I love Wikipedia :D

[@crabbyboi9127]

wont happen because 2108 will be the year of the linux desktop

[@itslolziee]

bold of you to assume anyone will exist by then

[@laka1469]

Two corrections: 1: The unix timestamp was changed to 64 bit a while ago to combat the 2038 problem. Full support exists since kernel version 5.6 (which came with Ubuntu version 20.10 in 2020). It is possible that some apps haven't been recompiled since then, but it's highly unlikely. 2: The unix timestamp is stored in 2s complement. The first bit is not a sign bit, it's -(2^63).

[@enochliu8316]

EXT4 file timestamp is also extended by two bits.

[@gabrielschilive7675]

It is not _effectively_ 64-bit, it is 34-bit and the minimum value (seems) to be still what he said. It is very odd, but you can check it in the kernel docs. It seems I cannot actually write the link here, but you can find the link by Googling "struct inode linux". Also, it is really pedantic to say you cannot call it a "sign bit"; people call it that, because it defines whether the number is negative.

[@PhoxKiD]

All negative numbers start with 1 for 2s complement

[@phucminhnguyenle250]

Unix timestamp is stored in 2s complement because that's how integers are stored. And the first bit is the sign bit.

[@netkv]

even then ext4 seems just 32bit, oldest it can do is 1901 weird

[@PerMejdal]

Plank seconds since the Big Bang. Needs 202 bits to represent the current time. With 256 bits we can represent 10^26 years. Which is long after all stars have burnt out.

[@Blue-Maned_Hawk]

That may not be enough time. The black hole at the center of milkdromeda will take over 10^91 years to decay, and energy harvested from a black hole could sustain a civilization.

[@theapexsurvivor9538]

Unfortunately, assuming that A. We don't go extinct before achieving a galactic diaspora, and B. Proton decay doesn't occur first, we actually need at least 10^10²⁶-10^10⁷⁶ years available, as that's the end of the Iron Star Era (where stars fuse almost completely to iron-56 before finally getting so cold that any which Can will collapse directly into neutron stars and black holes, sparking the second Black Hole Era before the lights finally go out, but time is kinda broken during that period). After that we'll all be basically just running on the most efficient computers possible (low background temperatures mean we can almost reach the Landauer limit) sat in the throat of black holes that we specifically engineered to last as long as possible, so time will be dilated to the point that it's kinda pointless to keep track of anything beyond subjective time, especially when the only thing you'd want to do outside of your black hole is go to Milliways for breakfast, and luckily we can use Bgg (Before gnaB giB) notation for that, and then you just have to be there by 00:00:00:000 on 00/00/0000.

[@megadev3727]

Just use a PB smh my head

[@ScienceD9000]

Lets use 512 bits, that goes out to 10^103 years. That should hold out to the end of black holes.

[@DefaultFlame]

Now we just need a 256-bit operating system and hardware . . .

[@8-bitcentral31]

Damn 1600s kids are going to be pissed when they relise that their files don't display the proper date in file explorer.

[@ahscott2001]

Not good enough. If I can't right click on the Magna Carta and get Date Created: 1215 AD, why even have a computer?

[@claytoncallaway6412]

it's vital for me to know when the epic of Gilgamesh was written when I click on it

[@netkv]

intrestingly linux can do that, but on tmpfs or with nilfs2

[@EbonySaints]

You get the Peace of Westphalia and you will like it.

[@GaryCameron780]

The word is "epoch".

[@Roxor128]

And when someone screws up their time and date handling, you have an Epoch Fail. Yes, there's a subreddit for it. I checked.

[@markjreed]

...and it can be pronounced exactly like "epic". In fact, that's the primary US pronunciation; "ee-pock" is the primary one in the UK, but both are acceptable both places.

[@DefaultFlame]

@@markjreed The US is wrong.

[@markjreed]

@@DefaultFlame in oh so many ways, but pronunciation is not a right/wrong thing. No matter what example you pick you will find widespread disagreement all over the English-speaking world. The language may be named after England but that doesn't convey dictatorial control over it - and you hear "epoch" as "epic" even over there.

[@jmvr]

​@@markjreed weird, because here in the US I've only ever heard it as "ee-pock" (I don't work a CompSci job tho)

[@Deh9o11en8or]

For windows it's probably to simplify leap year calculations. Those repeat on a 400 year cycle in the gregorian calendar and 1601 is the first "year 1" of a cycle after it was introduced.

[@Leuel48Fan]

Should've brought up the Year 2038 problem! Signed 32 bit seconds from Jan 1 1970 UTC 00:00:00 overflows back to the 1901!

[@nathanielhill8156]

This is a fixed issue. Ubuntu 20.04 supports signed 64 bit UTC. The files app just hasn't been recompiled to 64 bit. Apps are expected to recompile in 2026 when 32 bit Ubuntu reaches end of support.

[@Leuel48Fan]

@nathanielhill8156 Yes, I know. Many OSes have moved to 64bit the last decade from Linux to Windows and even iOS/Android. Just saying was worthy of a mention in the vid

[@stanstrum]

5:20

[@BinglesP]

Close enough. Welcome back Y2K bug

[@phucminhnguyenle250]

1582 is the year the Gregorian calendar started, but not the year at the beginning of the 400-year Gregorian cycle (1/1/1601 - 31/12/2000) in which the Windows system was developed. And 1601 was chosen because it would make it easier to calculate how many leap year has passed. This is necessary to readjust the amount of year calculated from the number of days since the beginning of the calendar epoch The calculation if it starts at 1601: leap_year_passed = year/4 - year/100 + year/400 The calculation if it starts at 1600: leap_year_passed = (year-1)/4 - (year-1)/100 + (year-1)/400

[@illuminoeye_gaming]

ok this is a great video but its driving me crazy that you keep calling the Unix Epoch the "unix Epic"

[@DefaultFlame]

Same.

[@tzarg]

yeah, I felt like I was going crazy because I always pronounced it how it's spelt, and the way he was pronouncing it made me feel kinda stupid

[@DefaultFlame]

@tzarg You are not stupid. Epoch and epic have vastly different meanings and spelling. Pronouncing them the same is what is stupid.

[@AwesomeAdmirak]

@@DefaultFlame Google "Epoch pronunciation" and revel in your ignorance

[@willmungas8964]

It’s pronounced that way though. You can put a little more emphasis on the “o” sound but you don’t have to

[@allypost]

I really can't tell if you called the Unix Epoch the Unix Epic accidentally or as a bit

[@p0xygen]

"on purpose or as a bit", so in both cases it would be on purpose then

[@abdou.the.heretic]

​@@p0xygen*silently edits comment* 😂

[@stefanalecu9532]

​@@p0xygen the difference would be incompetence vs malice (yeah, shoving Hanlon's razor here in a hyperbolic way)

[@bactrosaurus]

He put the epic games Logo, so...

[@gabrielrochadasilva3183]

He used the correct word elsewhere in the video. It's a bit.

[@boriszakharin3189]

I thought this would go in a different direction, documenting the oldest files in the history of computing. The term was used in computing as early as 1940, but the oldest file still in existence today appear to have been recovered from the Ferranti Mark 1, circa 1951.

[@haph2087]

The Gregorian cycle is: Every year%4==0 is a leap year (every 4th year) Except every year%100==0 is not a leap year (every 100th year) Except every year%400==0 *is* a leap year (every 400th year). The advantage of aligning the start date to the beginning of a cycle (that is aligning it with start%400==0) is that if you don't, you'll just have to constantly subtract the difference between the start date and the beginning of a cycle for these calculations and then re-add it once you're done. Imagine doing FizzBuzz, but you're starting at the number 4. Instead of adding and subtracting four all over your code, you can leave 0 as 0 and just initialize your iterating int to 4 and not bother with it. The same is true of calculating leap years starting in whatever year they were making windows.

[@NathanDudani]

The Anglosphere still used Julian until ca. 1750-52

[@haph2087]

@@NathanDudani The history of the Gregorian calendar is completely irrelevant to the easiest way to write the code. It would only matter if you actually wanted to support pre-1750 file ages, which evidently nobody cares much about. To clarify, I described the implementational conveniences of writing the first date as 1600, not reasons we care about .png files made in 1601, because very few people do. 2000 would be the next value with a comparable convenience, but actual computer files from before then exist, and likely most of the standards shown here were written before then.

[@General12th]

My grandparents say they were born before the UNIX epoch, but I don't believe them.

[@Randarrradara]

Impossible

[@namesurname4666]

there might be some viewers here born before the unix epoch

[@SouradiptaPlays]

No way bro that's NOT possible

[@balo720]

@@SouradiptaPlays Dude my grandad was born like 25 years before it. And he smokes and drinks as well man he's god

[@ignormies]

8:12 If I had to guess, the 7 minute timezone offset is due to local solar time from before timezones were standardized. There's an article called "pytz: The Fastest Footgun in the West" (can't comment with link) that discusses very similar issues in the pytz Python library

[@ProfessorMembrane373]

Swift's Date.distantPast and Date.distantFuture have absolutely nothing to do with APFS file systems, it's just a particular date chosen for a programming language. So no, macOS doesn't claim those dates are supposed to be representable as file dates. This also explains why the actual values for Date.distantPast and Date.distantFuture are not listed in the documentation - point is, you are not supposed to rely on those values, and if exact values were listed, then someone might do that.

[@redyau_]

Yeah, they are only supposed to be used like double.Infinity and such. For comparisons that never fail, etc.

[@cewla3348]

so why include them in the language? if you're not meant to use them, it seems very redundant and anti-learner to include them without a "WARNING: THIS SHOULD NOT BE USED. USE [[actual value]] INSTEAD" like in the MDN web docs.

[@ProfessorMembrane373]

@@cewla3348 They are supposed to be used. As other commenter mentioned above, it's useful for comparisons. Basically like +-Infinity but for dates.

[@RepChris]

The reason the leapyear dosnt line up with the initial gregorian calendar, but with 1601 is because the calendar was designed to make the math easy, the same reason 1601 was chosen by windows. Essentially there are approximately 365.2422 days in a year. The Julian calendar approximates this by having an extra day every 4th year (leap year). This is a pretty good approximation 365.25 vs .2422, but the calendar still drifts by about a day per century. This had gotten pretty noticeable by the 16th century, since it already drifted by half a month! How do you get to a value that exactly reflects the .2422? To get exactly there youd need leap years at weird intervals, so lets approximate. The julian approximation is already pretty close, but the second decimal is off. Lets adjust it to the correct decimal. It is over by exactly 1/100, so lets skip the leapyear every 100 years. Since it is easiest to remember to do something every 100 years if its on multiples of 100, and were good christians, lets have that happen on the years divisible by 100. Now we are under by 0.0022. Multiples of 4 are pretty easy, and 1/400 is very close to 0.0022. So lets not skip the leapyear every 400 years. Again aligned to the year 0 (Well technically there is no year 0 in the Gregorian calendar but the math still stands) for religious and practical reasons. Due to the drift we are already half a month off, so we have to move the date by a few days anyways, and adding or removing a day to make the leap year business much easier in the long run is definitly worth it. The calendar was created in the 1580s, and the next multiple of 400 is of course 1600, which is why that is the first year of the new epoch. As a nice side effect since the 400 cancels out the skipping of the leapyear that now happens every 100 years, the first time there is a deviation from the previous procedure (i.e. no leapyear when there would have been one before) dosnt happen until 1700, leaving everyone a lot of time to prepare and figure their shit out. TL;DR: The math works out a lot nicer if it happens on multiples of 400, and not on offset multiples of 400. The exact same reason Windows chose the same date (because the calendar was set up to make it easy like that). The time of adoption from different nations dosnt have any bearing on 1601 being the start of the epoch, the only adoption the adoption of Anno Domini dating during the Carolingian Renaissance, setting 1 AD as year 1, making the leapyear rules on the centennials line up with our current system of counting years (it would have most likely still been on the years we call 100,200,300,..1100,1200,...,2000,2100,2200,2300, etc. since that is a lot less ugly and convoluted, but they would have been different years speaking absolutely). To clarify why its 1601 and not 1600 as the start year: The epoch goes from --01 to --00, not from --00 to --99 because thats how years are usually grouped (e.g. the 3. century started on 301, the 21. century in 2001) because the AD system has 1BC followed directly by 1AD, meaning the 1. millennium, 1. century, 1. decade and 1. Gregorian cycle all started on year 1. So the cycle that was in effect before 2001 was the one that started 1601 (predeceased by the ones starting on 1201, 801, 401, and 1, etc). The fact that that also just so happens to be the first cycle where the changes from the Julian system in regards to leap years would happen after the calendars introduction is just a coincidence.

[@VividBagels]

but didn't people celebrate the turn of the millennium in 2000, and celebrate new decades in 2010 and 2020? it seems we mentally divide eras starting at ---0

[@drseek8961]

Historically, the UNIX timestamp was not always defined as starting at January 1st, 1970 and measuring seconds. Originally it was defined as: " time since 00:00:00, Jan. 1, 1971, measured in sixtieths of a second" and there is also a bug mentioned: "The chronological-minded user will note that 2**32 sixtieths of a second is only about 2.5 years." (Source: UNIX version 1 man 2 time).

[@snowwsquire]

just because swift has a time datatype that goes back to the year 1, doesn't mean the filesystem would also support that

[@_GhostMiner]

When you think it can't get worse than it's on Windows. Mac: allow me to introduce myself.

[@ragingmex5442]

The 1601 thing does make sense whn you consider the changes the geegorian calendar made to the Julian calendar, a leap year in the Julian calendar just happened every 4 years, in the Gregorian calendar its every 4 years, exxept if the year is divisible by 100, except if the year is divisible by 400, so 1700 is not a leap year but 1600 is, this is a pretty reasonable point to start/end an epoch this system, whwther it is the start or end is mostly arbitrary and i guess whoever was in charge of this at Microsoft decided that the 400 year is the end of the epoch, thus 1601 was the beginning of the epoch that ended in 2001

[@Ligands23]

7:26 HAH, I wheezed! Interesting video! Gotta love Apple oddities.

[@slamburger]

Really cool video

[@olivers.7821]

Exactly what I need to watch at 3 am on a Friday.

[@RAIN_B0T]

who needs sleep if you can get answers to questions you never asked xD

[@zacharyarney1095]

1:00 I love how Unknown is a more popular operating system then Linux

[@mapg519]

While freeBSD it's at 0%

[@BaileyMagikz]

Dev Detour: files can only be as old as 1970 people who saved files in 1969 and prior: am i joke to you...😂

[@bauckrob]

There is a reason file formats has internal metadata. For example, the proper place to put the date of a picture would be the exif metadata. That will stay with the file also if you copy it, etc. The file system timestamps has semantics from the os. It's file creation time, not authored date.

[@robvdm]

5:40 I think this is the first time I’ve head “everything just works” to describe Linux.

[@TheCommunistRabbit]

Nothing ever just works 😭

[@nathanb011]

Clearly you have never experienced the bliss of printing something on Linux compared to Windows or Max

[@robvdm]

@@nathanb011 oh I have. It took me like two hours to install and configure CUPS properly on a network printer.

[@eduardandrejev]

⁠@@robvdmbut everything just works! They never specified how well… (i use both, Linux and Windows 🤷🏻‍♂️)

[@insu_na]

​@@robvdmwhy would you install CUPS on a printer of all places? Just use a separate print server like a normal person

[@IHaveLagz]

Weirdly enough, on iPad and iPhone the minimum is January 1st 0001 at 12:00 AM

[@IHaveLagz]

The maximum is also December 31st 4000 at 11:59 PM

[@Angelaaal]

5:12 so that means on the january 19th 2038, ubuntu just can't tell the time anymore? Or jumps back to december 13th 1901?

[@general_wcj9438]

I was wondering the same thing. Turns out Ext4 cheats a bit, theres a different field for storing nanoseconds, that has 2 extra bits. The way these are encoded allows one to get up to 15032385535 seconds past the unix epoch which is in 2446, at which point hopefully this isn't a problem

[@arturpaivads]

That's the year 2000 problem of epoch time. Honestly the solution is just to migrate to 64 bit integer for time, that's basically the "official" solution. Ext4 just didn't do it yet. Probably by them we will have a patch or outright ext5. And yeah, if left unfixed it will jump back to 1901. You can try with an older system in 1938, or by changing your clock.

[@petersilva037]

The video is just wrong... the linux kernel moved to 64 bit time stamps a while ago. so the range is something like 2**63-1 ... rather than 2**31-1

[@peterholzer4481]

@@petersilva037 True. However, the ext4 filesystem doesn't have space for the full 64 bit range, just for 34 bits. And it's not symmetrical around the epoch, so the range is really from -2147483648 to 15032385535 (as @general_wcj9438 noted), and the video is correct that the earliest timestamp you can have on an ext4 file system is in 1901, just for the wrong reason.

[@netkv]

@@petersilva037 but filesystems didn't

[@hadrionics2755]

Computers can't handle files that are too old: Panik They can actually handle files from well before computers even existed: Kalm We need to store files from other planets in the Galactic Alliance which developed computers while we were still in the middle ages: PANIK

[@tastycheesegeo]

4:08 how did you know

[@urncjd]

I was just about to ask the same question

[@Cloud67TR]

HOWWW????

[@commander07]

The file explorer limit is 100% from the MS-DOS limit. If you dig deeper you will that most MS-DOS file system limitations exist in file explorer, such as dots (.) at the end of files or directories refusing to be opened despite NTFS fully supporting them.

[@eMorphized]

Microsoft made a kernel that best supports an objective workflow, and has basically no limits, and then forced it to basically emulate Windows 95

[@m4rt_]

It makes sense that Apple also uses the Unix Epoch, as it's also Unix. It's a fork of FreeBSD

[@eMorphized]

It just borrows the BSD userland because of the license. It has nothing to do with BSD under the hood. It's Unix for other reasons.

[@bruce11121314]

Are you using the native macOS tools in terminal or did you happen to install gtools from brew to give you the GNU versions? That might explain why you see different behaviour with ls, since macOS by default ships the BSD version of it

[@mustafaazyoksul1372]

2:41 January 1st, 1601 is not arbitrary. It is the first day of the 17th century.

[@ShadrolGER]

The first day of the 5th gregorian cycle.

[@NathanDudani]

*March 25th, 1601

[@ckingpro]

For Windows, it is because Microsoft designed NTFS beyond Win32. It supports POSIX API and features as well as alternate data streams to support Mac's resource fork features.

[@toastbucket]

I think a follow up to this video investigating what the oldest computer file that still exists on an active machine is would be cool

[@circleinforthecube5170]

voyager one files are up there,

[@Korubiiii]

This video isn't even about how old a file can be. This video is about the oldest date you can set a file to. Finding how old a file could ACTUALLY possibly be would have been a lot more interesting imo.

[@MrDaAsif]

I agree and that's also where I thought it was going, a chain of I/O from something ancient to modern

[@Taima]

I was kinda hoping you'd also tangentially wonder/look into what the oldest actual files are, like not artificially dated, but actual files that from their creation at some point in the past have made it to today.

[@Acre00]

I'm so happy the Tom Scott videos are still being referenced

[@BlackKnightsCommander]

Hey, just so you're aware, if you make an entryway in a masonry building, using corners to shape the top part gives it two much weaker spots for it to fail on. Using a curve instead of any corners makes it much stronger. I use Arch btw

[@quirrelfromhollowknight]

I fell asleep to this. Now I’m a comically old file.

[@thogameskanaal]

It's possible that the January 1st, 1601 timestamp could be linked to digitized historical texts and codices in some cases, particularly in libraries or museums. The adoption of the Gregorian calendar began in 1582, but it wasn't universally adopted by all countries until later, and 1601 is around the time when many regions in Europe had made the transition.

[@bryceio]

The Epic logo at 4:20 jump scared me.

[@mrphlip]

Timestamps in ext4 are actually stored as some wacky 34-bit integer... but it's offset so that it can go down to minus 2 billion but up to about plus 15 billion. So the earliest time is still that same time in 1901 and the zero point is still 1970, but it can keep counting forward after 2038, the maximum date is in 2446.

[@Fudmottin]

It's about time.

[@Vemu]

wtf is going on with mac

[@andreea-mgh]

they will say this is innovation and use this as a reason to charge you another 200 bucks

[@CharleyWright-w1y]

From Apple's perspective Swift is not Mac. There is no requirement that a Swift date can be represented on an Apple filesystem because Swift is just a programming language. The reason the docs don't show the exact dates for distantPast and distantFuture is because these values should not be relied upon, if they were in the docs people would be much more likely to copy them into their own code then blame Swift if their code breaks. Not saying it is a good system, I don't particularly like Swift as a language or many of Apple's decisions, just thought I'd shed some insight.

[@threesixtydegreeorbits2047]

1677 on Mac is just as good as 1601 on Windows because Mac is more time efficient. 💁

[@whamer100]

question of the century

[@CorporateShill]

@@CharleyWright-w1yfinally, an actual nuanced answer. Not some dumb overused jokes

[@carking0138]

When I first saw the video title and clicked on the video, I fully expected to find out what the oldest file ever made (with a computer format) was. I am now angry that I assumed this, because I really want to find this out now.

[@Kwpolska]

The "cycle" that produced 1601 is related to leap years. Leap years occur every 4 years, but they don’t in years that are multiples of 100, but years that are multiples of 400 are leap years. The "cycle" is 400 years, the last one is the leap year divisible by 400, in this case it was 2000.

[@PlanetXtreme]

I enjoyed all the hidden jokes in your videos, including the very real public jokes towards apple

[@John-u6k]

Wild that this video only has 600 views

[@stonium69]

For Windows and Linux you could at least *try* to test what happens when you make files older than what wikipedia/chatgpt says about the operating system's limits? It's evident you didn't given your info on Linux is wrong specifically, but also because it would be an interesting thing to show.

[@devdetour]

Thanks for your comment - though I didn’t show it, I did try values outside of the published minimums. They just get set to the minimums in Ubuntu, and Powershell throws an error message. If you look around the 5:00 mark, the C program I run has a comment about how I also tried with a LONG signed int and got the same result. I am on 64 bit Ubuntu and the 32 bit thing seemed wrong to me so I actually dug into the header files dealing with time to confirm - there IS a check for if 64 bit time is supported, but on my stock installation with stock GCC, it never was true (I added a compiler error to the inside of the block, which never tripped). I’m sure other distros work with 64 bit timestamps, but from what I was able to find, Ubuntu currently doesn’t.

[@soejrd24978]

amazing, I wouldn't want to have not known this for me useless information

[@danielbickford3458]

You know I was half worried to find out that some computer types have a built-in file kill code after a certain date

[@greg_pizzatower]

1:42 if that's old greg, then i'm new greg

[@ZReChannel]

4:09 how did you know man

[@Berries1111_]

9:51 one millionth of 2^63

[@m4rt_]

btw, Unix time is moving over to 64 bit (or already has moved over, I can't fully remember), as with a signed 32 bit integer, it will run out of space in 2038 (19 January 2038 at 03:14:07 UTC) with 64 bits it could go about 292.3 billion years in both the past and the future. (Which is about 20 times the age of the universe.)

[@harlow49]

There goes my dreams of digitizing my 16th century family photos 😔

[@markjreed]

The 1904 thing goes back to the well-known Lotus 1-2-3 bug (inherited by and still visible in Microsoft Excel) that made 1900 a leap year, when in reality it wasn't one because of the centennial leap-year rule. To avoid having to deal with that mess, Apple skipped forward to the next year that everyone agreed was leap, 1904, which was the epoch for classic MacOS back before it was based on UNIX and switched to the UNIX epoch. The 0001-12-30 thing could also be related. Lotus intended that day number 1 should represent Jan 1, 1900, but because of the leap year bug, day 1 wound up on Dec 31, 1899 instead. Which means day 0 is Dec 30, 1899 - which is again still true in e.g. Google Sheets. I don't know how you get from there back to December 30 of the year 1, but it is at least an example of how several modern software systems wound up with day 0 on the 30th of December.

[@presto668]

The Lotus 1900 leapyear thing *probably* was deliberate. They didn't have a lot of CPU power or memory to work with when they were writing Lotus, and if you ignore 1900 you can tell if a year is a leap year just by looking at the last two bits (ie, if (year & 0x3) { not a leap year } else { leap year }). This is cheap and fast.

[@TechXSoftware]

Up next, how old can an OS be.

[@Wobuffet3]

this is pretty neat, but i thought this was going to be about the oldest files in existence. i vaguely remember downloading a zip file with some random junk from the mid 70s haha

[@chrideedee]

I checked for HFS+ (older Mac OS filesystem), and according to the documentation (TN1150), the range is January 1, 1904 to February 6, 2040. However, the touch command lets me set times back to the earliest Unix timestamp (in 1901) and March of 2040 (I didn't try going past that), and ls seems to show both dates correctly (though Finder shows "--" for files older than 1904), so I don't know what's going on there. I hope I didn't break anything.

[@chrideedee]

I just tried the same thing in a new disk image, and got the same behavior (I could set a file to be modified before 1904 and it would be displayed correctly), but then I unmounted and remounted the image and the date wrapped around to 2038, so I think (in my case) the modification time is probably just being cached somewhere that can store a bigger range of dates than the actual filesystem. This *also* means that just finding the earliest/latest date by experimenting like this might not be conclusive-the date on your really old or far-future file might change if you restart your computer.

[@RokeJulianLockhart.s13ouq]

​​​@@chrideedeeah, they're probably cached in a sidecar, like desktop.ini files. macOS tends to leave similar cruft around filesystems.

[@vadimuha]

There's a lot of 100-nanosecond intervals since Jan 1 1601. Is 32bit unsigned integer enough to represent it?

[@madbanana22]

probably the "high" value gets incremented by one when the "low" value overflows

[@Radar_of_the_Stars]

time slop, -10 social credit

[@Chiberia]

Most of these odd first dates are likely dictated by the maximum value being a reasonable end date. It would make more sense for FS developers to consider the latest date a file can be far more significantly than the earliest.

[@megapro1725]

That cope when you said still the most popular operating system. For now. It will always be, when competitors are not usable, especially router firmware a.k.a linux

[@isheamongus811]

2:44 good reason. For a year to be leap it has to be divisile by 400 or dividible by 4 but not 100

[@TheColinputer]

I have always figured that APFS at some point stood for Apple Proprietary File System. But later they decided 'proprietary' sounded bad so removed it

[@jalmarihuitsikko7211]

Some years back i was still working on a system that could reset time to seventies when battery ran out. That system had like flexos, win 3.11 and ms-dos 6.22 or something. This was pretty common back then before internet connection when time sync was not a thing.

[@xiandnico]

8:33 error here, september speaking but shows december

[@realDesertLad]

Also related to an older comment I made - why not other formats like exFAT or Apple's *previous* file format HTFS that older versions of macOS run on?

[@ccriztoff]

why is a date a specific date? A programmer. Whether personally, arbitrarily, or based on ignorance.

[@chaaaake]

Clicked on this video with a different understand of the title so now I’m curious, what is the oldest computer file that’s still floating around and accessible today?

[@enginerd80]

7:40 The 0001-12-30 looks to me like it's trying to make it obvious which part of it is which (year, month, day). There are 12 months in a year, and 30 days is a common length of a month, so those would tell which is which. Only the year is a bit weird, but on the other hand there probably aren't clear numbers that would show that the number is specifically year, but on the other hand it's four digits like the years have been and will be for quite a while. And 0001 is the first year (though with leading zeros) of the calendar that is in use.

[@angeldude101]

It's the ISO 8601 date format, and I pretty much use it exclusively for purely numerical dates. The more common formats using slashes are _far_ too easy to confuse with each other. ISO 8601 also has the nice feature that it mirrors the way we usually write numbers, as well as time, with the greatest magnitude on the left and smallest magnitude on the right. Follow the date with the time and each field is strictly less then the one to its immediate left. Technically ISO 8601 is supposed to have a T in between the date and time, but I usually consider it unnecessary, and most things tend to accept its absence.

[@eee_inn2658]

5:19 is that integer really in 1's complement? It was my understanding that 1's complement is almost never used in favor of 2's complement

[@devdetour]

It is meant to be 2’s complement, and I believe animated correctly - max positive number is 0 followed by all 1s, min negative number is 1 followed by all 0s. I double checked this in the edit with one of those binary-to-int sites and also Python.

[@parad0xheart]

Seems that the Linux interpretation of file timestamps is file system specific too. ext4 is bound by a signed 32-bit integer but on a system using ZFS I was able to set the year to an essentially arbitrary number from 0 to 999,999 and it just worked.

[@SebastiaanFranken]

FYI, Linux also does it's UNIX Epoch code as a 64 bit signed int as well, for quite a while.

[@AdrX003]

It might be a dumb question but why they didnt just make it like a ID3 tag/text box allowing only the numbers and known words for dates in a predetemined format and space that would be needed? It seems plausible at least to me if you really needed something to show dates before and or after any system could show.

[@callofbrokendreams]

8:29 never expected i would learn about an odd piece of history about my country here. it is funny how they really thought '5:45' looked cleaner than '5:40'

[@DevinDTV]

The Gregorian calendar has leap years and centennial years. Leap years are every year divisible by 4 and not divisible by 100. Centennial years are those divisible by 400. The year 1600 was a centennial year, 1601 was the first year after the last centennial year as of the 20th century, when Windows was made.

[@legolegs87]

That's all good but what if you have to deliver an historical file by getting it using ftp, zipping, burning to a CD? How screwed up the mdate would be?

[@S_P_A_C_E_DD]

The 400 year cycle is to do with leap years. A leap year occurs in each year that is a multiple of 4, except for years evenly divisible by 100 but not by 400. The last time the 400-year rule came into play was the year 2000 and the previous time before that would have been 1600. Not sure why the first year is 1601 instead but there you go.

[@phucminhnguyenle250]

1601 would make the calculation for the number of leap year prior to the current year a bit shorter. This is needed to readjust the year after taking the raw number (by divide the number of days by 365) For 1601 it is year/4 - year/100 + year/400 For 1600 it would be (year-1)/4 - (year-1)/100 + (year-1)/400

[@E_Fate]

My English is not good enough to understand the hole video but this means that if I record a video and write a txt document in 2024 and let it in my computer and a drive for the year 2200 archeologist and anthropologist to read it and play it, can they still opened it or does it die (the files) at some point?

[@maeborowski1315]

I have a photo on my iPhone from April of year 1. Unrelated to macOS, but cool that it shows up.

[@arnothar8035]

You talked about using 32-bit time measurement in Linux. That is correct for a 32-bit Linux version. With 64-bit, the value can be much bigger (64-bit measuring was introduced because of the value overflow in 2038, which is soon) or much smaller because 64 bits are used here. With a 64-bit signed integer for the number of seconds, the minimum value should be about January 1st in 292 Billion BC.

[@gSys1337]

The oldest legal file dates back to the first computers. Therefore the lower bound is 1940.

[@karlkastor]

I was not gonna watch this, because surely it's 1970. Glad to be proven wrong, interesting stuff

[@Davide0033]

i didn't expect macOS to be the most cobbled togheder mess

[@xanderplayz3446]

11:36 When Dev Detour’s inner carykh shows. Is it just me?

[@P7777-u7r]

I want to start a new religion based on machines and computers and I want my date to be perfect. We need to find out whatever the oldest ACTUAL computer "file" is and the day it was made and make that the year "0"

[@Chubby_Bub]

I still wonder what's going on with Finder's time zones but that might be even more of a pain to figure out.

[@kalebakeitshokile1366]

Haha speaking of Tom Scott. I bumped into him in London the other day

[@hridgreximp6194]

For some ungodly reason, I have had a file on iOS from over a decade ago displaying as April 10th 112030…

[@ryanmccampbell7]

1600 or 1601 make sense as the start of the cycle because the calendar has special cases every multiple of 100 and 400 years, so 1600 and 2000 have leap years while 1700, 1800 and 1900 don't. That doesn't really explain why not 1600 though.