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.
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.
@@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.
@@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.
I did some searching online, and it seems like nobody has an exact answer, but it's likely from the 1950s. This was when the first computers with permanent storage were created, and some of them have survived up to this day.
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
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.
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.
I mean... Kinda, I guess? The oldest "originally digital" file couldn't be before 1951 when they started using magnetic tape, and if you include digital files from reading in punch cards or something, that can go back as old as you can dig up an old program from somewhere.
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.
@@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.
@@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.
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.
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.
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.
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).
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.
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.
...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 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.
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.
@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
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
The first version of the UUID based on the RFC standard actually started on 15/10/1582 as its epoch and counted tenth-microseconds like Windows does, which I found very interesting since to most people it would seem very arbitrary. They also limited the timestamp to 60 bits to make room for the clock sequence bits, which means that UUID V1 will overflow after 8/6/3409, 22:40:30.3423487. Using a signed 64-bit integer this would be good up until 28/6/30810, 02:48:05.4775807 using signed integers or 11/3/60038, 05:36:10.9551615 using unsigned integers (which means that, had this convention become common, programmers in the 6001st century would have to deal with Y2K38 all over again).
oh, i thought this video was going to be trying to figure out what time a human physically could have created a digital file and then going deeper into what counted as a file in early computers
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 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.
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.
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
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.
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.
I'm an ex forensics dev. We used to take extra care to properly extract even the weirdest file time metadata, but the average user typically complained if it was before 1970, so we ended up with a few workarounds to discard values which users wouldn't believe, even if that was _literally what the metadata said_. We got questions about those wack time zones too, for the dates which were sufficiently far back. Well, before time zones were fixed, everyone used to use their actual offset based on the city they lived in. So TZDB occasionally records that sort of trivia and uses it for sufficiently old dates. So for example, the time zone Australia/Sydney has an offset of UTC+10:04:52, until Feb 1895. Also, 2001 and 1601 were probably chosen for the same reason - it's the first year after a leap year, which makes leap year calculations much more convenient.
The only time I've seen files that actually had dates that weird were from corrupted filesystems or something, but that's probably what you were getting, too :)
Opening this video I thought "Unix Time, 1970", but you too said that immediately. Then I remembered I once had corrupt files on a USB Stick dated to 1901 and I was curious if that year would come up and lo and behold - Unix time, but negative. Neat!
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.
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).
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
About ext4, it supports two formats for storing dates: when using 128-bytes inodes it stores them as signed int32_t values relative to epoch. However when using larger inodes it uses a way more different format which in addition to the original signed int32_t it uses an additional 32-bits structure composed of: * 30 bits (unsigned) used for representing the number of nanoseconds (you could think about them as if they were divided by 10⁹ and added to the original timestamp) * 2 bits (unsigned) that are multiplied by 2³² and then added to the original timestamp. This is why the range goes (in the small inodes form) from epoch - 2³¹ seconds to epoch + 2³¹-1 seconds; and in the large form from epoch - 2³¹ seconds to epoch + 2³¹-1+3*2³² seconds, in hexa (which is easier to visualize) the ranges would be -0x80000000..0x7fffffff and then -0x80000000..0x37fffffff, and in years the ranges would be 1901..2038 and 1901..2446. That means the oldest supported date in ext4 is in 1901 no matter if the system is running 32 or 64-bits code, or if your apps are using the syscalls built with ye-olde 32/64-bits time_t or the new 64/96-bits struct timespec { time_t tv_sec; long tv_nsec; }; Yes, in some cases it's possible to have a 64-bits time_t in 32-bits systems. Hopes this adds more clarity on ext4 timestamps.
8:22 I know this one! 1677 is before the widespread adoption of railroads and before railroad time. Every city has their own clocks and didn’t try to group into zones where it’s all the same time, or “time zones” if you will. So your city, or at least the one used for your time zone in the zoneinfo database, had to adjust by a few minutes to fit the time zone when it was invented
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.
Swift is a general-purpose cross-platform programming language, and it is not something that is tied with macOS. distantFuture is not a value related with APFS, but just something like Infinity but for dates.
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
Now here’s a better question, what’s the actual oldest file (not oldest date set on a file) that can be read on a modern computer without modification. You can copy from media using a reader but not alter the format to do so.
On December 21st, 1677, a significant historical event was the siege of Cambrai, which was part of the ongoing Franco-Dutch war, where the French forces were laying siege to the city of Cambrai in the present-day northern France. I hope this helps...
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.
The question of the oldest currently preserved file with a timestamp attached that can survive a theoretical file system conversion (or a series of) up to a modern OS on modern hardware would be more interesting imo.
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.
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.
Thanks for this. As a kid, I once downloaded Kaillera for netplay, and the DLL claimed to be from 1633. I now finally know why the hell that was even possible.
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.
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
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 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.
Setting dates/times of original creation of something digitized, such as a photo, a vinyl record, or a cassette tape, is what meta data is for. The time stamps in the file system are intended only to record file creation, modification, access, etc., via the file system. Meta data is data used to record specific relevant information about file contents. This is information like the type of data contained in the file, the date a photo was taken, camera model used, an album title, song name, the author of the document, etc. The only thing that matters with file date/time stamps is consistency within the file system. And the operating system converts to/from it's own time/date representation by different amounts with different file systems the operating system knows how to access the contents of.
We couldn't figure out that the year was going to roll over in 2000 but by damn we'll go back to the 1700s and just in case you need to read some weaving loom punch cards
Every 100 years a leap year is skipped unless the year is divisible by 400. So the gregorian cycle is from 1601-2000 and then 2001-2400 etc. Therefore Microsoft decided to include the entire previous cycle to make the formula of calculating the actual date easier. the article was referencing adoption not the actual cycle time. I am kind of surprised someone at microsoft was thinking this far ahead but it is very valid.
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.
Note that the file date for the portable FAT system cannot be before Jan 1, 1980. This is the same default time that early DOS systems without a clock battery used. NTFS was based on a mix of FAT and some unix and VMS concepts, which explains the weirdness. And the Apple system is Unix-like under the hood, but some parts of the file system are based on the pre-OSX Mac OS, which, again, explains the weirdness. Both Windows and Mac OS have some backwards compatibility dependencies on non-extensible bit-sliced dates in older filesystems. The filesystem itself may use a signed integer based on the Unix Epoch, but the libraries for accessing the dates may do some weird conversions. Linux is more sane because Unix always used a signed integer for all dates and times. Extending that to 64 bit is simple. If you want to see some dare weirdness, look at mainframe operating systems written when every byte was expensive, but hex dumps on paper needed to be human readable. You have dates in BCD format often leaving out centuries - 1987 would be encoded as C8 C7 (and after a Y2K conversion, possibly 98 C7 as a 3 digit packed decimal)
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.
Now I wonder how old can a file be legitimately. No date editing, like, when was the first file that can be taken to something like windows and see the date
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.
The cycles of the Gregorian calendar are, by my understanding, just a happy accident. Any span of 400 consecutive years within the Gregorian calendar will be exactly 146 097 d = 20 871 wk. Had they chosen 1600, it would be offset from how we count centuries, which are the way they are because there is no year 0, as it goes 3 BC, 2 BC, 1 BC, 1 AD, 2 AD, 3 AD, etc.
Ok that's cool but now the next question is: What is the oldest possible digital file that was ACTUALLY written on the stamped date, preserved, and can still be recognized by modern computers? Somthing written by the ibm 704? The UNIVAC I? The manchester baby? Hell we could even have an entire philosophical discussion as to what even counts as a comouter file. Like if we connect a record player to a computer it can read them. Would that make the first vinyl record also the first comouter file? Would be an absolutely fascinating video
That's the oldest date you can set a file to, not the oldest actual file. According to Wikipedia, looms used data stored on paper tape as early as 1725, so the oldest actual data file stored on digital media is probably around 1725.
Re: macOS, it'd be interesting to see whether those mismatches between the POSIX parts of macOS and the Cocoa parts of macOS originate in OpenStep (where Cocoa has its roots in) or classic Mac OS via Carbon. I imagine they're at least partly the same as how many of Win32's warts were down to making sure that it'd be easy for Win16 programmers to transition their skills over.
“Why 1601 and not 1600?” Probably because it’s easier to measure from the beginning of a century rather than the new year of the last year of the century, lol.
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.
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.
In the Gregorian calendar: - a year divisible by 4 has a February 29th; - except a year divisible by 100 does not have a February 29th; - except a year divisible by 400 has a February 29th. 1600 is divisible by 400 and had a February 29th. This is why 1601 is the start of the current 400 year cycle. 1900 did not have a February 29th, and 2000 had one. By starting Mac OS at 1904, Apple would not need to think about all the conditions of the Gregorian calendar until 2100, the next year divisible by 100 which does not have a February 29th.
Windows has two time kinds: System time and file time. The Windows API has a function called SystemTimeToFileTime that converts one into the other. This is where the inconvenience comes from. Everyone that had to deal with Windows files has come across this annoying thing. One starts in 1601, the other one in the 1980s. It's documented pretty well also.
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
Check out Javascriptmas on Scrimba here: scrimba.com/javascriptmas?via=devdetour Thanks Scrimba for sponsoring this video!
6:52
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.
thank you very much
if i made a file system i would use my own system which goes back to 1582
XVIII is not thirteen.
Damn 1600s kids are going to be pissed when they relise that their files don't display the proper date in file explorer.
1600 kids: What is this shiny mirror thing? BLACK MAGIC?!! HERESY!!!
@@alanbareiro6806it's only black magic if you use dark mode.
the cycle started at 1601 because they probably aligned them in such a way so a cycle would start at the year 1.
This
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.
@@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.
@@mylittleparody2277 Well, they couldn't use 64 bit from the start. Because 64 bit hardware didn't exist yet.
@@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.
For some reason I thought this was going to be research into the oldest digital file still in existence.
Would’ve been a way better video
I did some searching online, and it seems like nobody has an exact answer, but it's likely from the 1950s. This was when the first computers with permanent storage were created, and some of them have survived up to this day.
The problem is that it's probably in some American government archive that's impossible to access.
@@Austin-gj7zj The oldest public digital file still in existence
I've found files in open directories with last modified dates from the mid-80s
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
As useful as Family Guy Compilation #211
no it isn't you troll
That's why we clicked it 🗣️
Thank you. Now, on to watching!
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
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
That was the most creative way of saying "I use Arch btw UwU :3".
3:37 some microsoft employee about to have a bad day on 30/12/2107 when they remember that
Someone should compile a list of all upcoming Y2K events
@@MrBen41234There's a wikipedia article for it
@KSPAtlas I love Wikipedia :D
wont happen because 2108 will be the year of the linux desktop
bold of you to assume anyone will exist by then
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.
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.
I agree and that's also where I thought it was going, a chain of I/O from something ancient to modern
I mean... Kinda, I guess? The oldest "originally digital" file couldn't be before 1951 when they started using magnetic tape, and if you include digital files from reading in punch cards or something, that can go back as old as you can dig up an old program from somewhere.
Then go do it.
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.
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.
Unix timestamp should always be 64 bit signed.. Never assume that anything or anyone can't be older than 1970 hahaha.
(For legal reasons, this is a joke)
So you're saying the solution is to eliminate all the people born before 1970.
@@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.
@@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.
calling windows still the most popular desktop algorithm "for now" is exactly what a linux user would say
linux user here, confirmed.
Cause once Microsoft ends up forcing shitty spyware on you, it goes downhill for Windows.
"the most popular desktop algorithm" is the phrase that only a luser would say
@@maddox5081 people have been saying that "the spyware will kill windows this time" for decades
@@maddox5081 You mean like they are already doing and have been doing for 15 years?
Not good enough. If I can't right click on the Magna Carta and get Date Created: 1215 AD, why even have a computer?
it's vital for me to know when the epic of Gilgamesh was written when I click on it
intrestingly linux can do that, but on tmpfs or with nilfs2
You get the Peace of Westphalia and you will like it.
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.
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.
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.
Just use a PB smh my head
Lets use 512 bits, that goes out to 10^103 years. That should hold out to the end of black holes.
Now we just need a 256-bit operating system and hardware . . .
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).
EXT4 file timestamp is also extended by two bits.
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.
All negative numbers start with 1 for 2s complement
Unix timestamp is stored in 2s complement because that's how integers are stored. And the first bit is the sign bit.
even then ext4 seems just 32bit, oldest it can do is 1901 weird
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.
This makes sense. "Is divisible by 400" is one of the leap year rules, so why not start on the first year after that rule takes place.
The word is "epoch".
And when someone screws up their time and date handling, you have an Epoch Fail. Yes, there's a subreddit for it. I checked.
...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.
@@markjreed The US is wrong.
@@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.
@@markjreed weird, because here in the US I've only ever heard it as "ee-pock" (I don't work a CompSci job tho)
1:00 I love how Unknown is a more popular operating system than Linux
While freeBSD it's at 0%
2025 will be the year of KolibriOS
Than.
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!
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.
@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
5:20
Close enough. Welcome back Y2K bug
and when will the 64 bit integer limit overflow?
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
The first version of the UUID based on the RFC standard actually started on 15/10/1582 as its epoch and counted tenth-microseconds like Windows does, which I found very interesting since to most people it would seem very arbitrary. They also limited the timestamp to 60 bits to make room for the clock sequence bits, which means that UUID V1 will overflow after 8/6/3409, 22:40:30.3423487.
Using a signed 64-bit integer this would be good up until 28/6/30810, 02:48:05.4775807 using signed integers or 11/3/60038, 05:36:10.9551615 using unsigned integers (which means that, had this convention become common, programmers in the 6001st century would have to deal with Y2K38 all over again).
oh, i thought this video was going to be trying to figure out what time a human physically could have created a digital file and then going deeper into what counted as a file in early computers
Same.
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.
The Anglosphere still used Julian until ca. 1750-52
@@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.
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.
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
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.
Yeah, they are only supposed to be used like double.Infinity and such. For comparisons that never fail, etc.
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.
@@cewla3348 They are supposed to be used. As other commenter mentioned above, it's useful for comparisons. Basically like +-Infinity but for dates.
My grandparents say they were born before the UNIX epoch, but I don't believe them.
Impossible
there might be some viewers here born before the unix epoch
No way bro that's NOT possible
@balo720how old is your granddad
?
@@Randarrradarathere are people older than 55 😑
I'm an ex forensics dev. We used to take extra care to properly extract even the weirdest file time metadata, but the average user typically complained if it was before 1970, so we ended up with a few workarounds to discard values which users wouldn't believe, even if that was _literally what the metadata said_.
We got questions about those wack time zones too, for the dates which were sufficiently far back. Well, before time zones were fixed, everyone used to use their actual offset based on the city they lived in. So TZDB occasionally records that sort of trivia and uses it for sufficiently old dates. So for example, the time zone Australia/Sydney has an offset of UTC+10:04:52, until Feb 1895.
Also, 2001 and 1601 were probably chosen for the same reason - it's the first year after a leap year, which makes leap year calculations much more convenient.
The only time I've seen files that actually had dates that weird were from corrupted filesystems or something, but that's probably what you were getting, too :)
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
voyager one files are up there,
just because swift has a time datatype that goes back to the year 1, doesn't mean the filesystem would also support that
Opening this video I thought "Unix Time, 1970", but you too said that immediately. Then I remembered I once had corrupt files on a USB Stick dated to 1901 and I was curious if that year would come up and lo and behold - Unix time, but negative. Neat!
I really can't tell if you called the Unix Epoch the Unix Epic accidentally or as a bit
"on purpose or as a bit", so in both cases it would be on purpose then
@@p0xygen*silently edits comment* 😂
@@p0xygen the difference would be incompetence vs malice (yeah, shoving Hanlon's razor here in a hyperbolic way)
He put the epic games Logo, so...
He used the correct word elsewhere in the video. It's a bit.
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.
Exactly what I need to watch at 3 am on a Friday.
who needs sleep if you can get answers to questions you never asked xD
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).
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
ok this is a great video but its driving me crazy that you keep calling the Unix Epoch the "unix Epic"
Same.
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
@tzarg You are not stupid. Epoch and epic have vastly different meanings and spelling. Pronouncing them the same is what is stupid.
@@DefaultFlame Google "Epoch pronunciation" and revel in your ignorance
It’s pronounced that way though. You can put a little more emphasis on the “o” sound but you don’t have to
About ext4, it supports two formats for storing dates: when using 128-bytes inodes it stores them as signed int32_t values relative to epoch. However when using larger inodes it uses a way more different format which in addition to the original signed int32_t it uses an additional 32-bits structure composed of:
* 30 bits (unsigned) used for representing the number of nanoseconds (you could think about them as if they were divided by 10⁹ and added to the original timestamp)
* 2 bits (unsigned) that are multiplied by 2³² and then added to the original timestamp.
This is why the range goes (in the small inodes form) from epoch - 2³¹ seconds to epoch + 2³¹-1 seconds; and in the large form from epoch - 2³¹ seconds to epoch + 2³¹-1+3*2³² seconds, in hexa (which is easier to visualize) the ranges would be -0x80000000..0x7fffffff and then -0x80000000..0x37fffffff, and in years the ranges would be 1901..2038 and 1901..2446.
That means the oldest supported date in ext4 is in 1901 no matter if the system is running 32 or 64-bits code, or if your apps are using the syscalls built with ye-olde 32/64-bits time_t or the new 64/96-bits struct timespec { time_t tv_sec; long tv_nsec; }; Yes, in some cases it's possible to have a 64-bits time_t in 32-bits systems.
Hopes this adds more clarity on ext4 timestamps.
Shoutout to the ancient, fried USB drive I have that shows bogus files with random dates varying from 1800ish to sometime far in the future
the Discordian calendar was a nice touch
the epoch misspelling as both a joke and engagement bait is delightful---so many people missing that
1:42 if that's old greg, then i'm new greg
7:26 HAH, I wheezed!
Interesting video! Gotta love Apple oddities.
Really cool video
I never thought about sitting in a historical photo's timestamp today it was actually taken, that could be very useful.
8:22 I know this one! 1677 is before the widespread adoption of railroads and before railroad time. Every city has their own clocks and didn’t try to group into zones where it’s all the same time, or “time zones” if you will. So your city, or at least the one used for your time zone in the zoneinfo database, had to adjust by a few minutes to fit the time zone when it was invented
I enjoyed all the hidden jokes in your videos, including the very real public jokes towards apple
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.
i love how in windows and linux you can edit the creation and last modify date on a file, makes it so easy to fake dates to make ARGs and stuff!
The ending bit genuinely made me wheeze out loud, wasn't expecting it
"More on that later"
Didn't realise i was watching Dev's Game Dungeon
Swift is a general-purpose cross-platform programming language, and it is not something that is tied with macOS. distantFuture is not a value related with APFS, but just something like Infinity but for dates.
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
There goes my dreams of digitizing my 16th century family photos 😔
Now here’s a better question, what’s the actual oldest file (not oldest date set on a file) that can be read on a modern computer without modification. You can copy from media using a reader but not alter the format to do so.
When you think it can't get worse than it's on Windows.
Mac: allow me to introduce myself.
me: hmm, really how old can a file be?
dev: (weird information about weird old guy)
We should switch to using floating point numbers, that would be way more fun. "What time is it" "idk bro I'm scared"
I fell asleep to this. Now I’m a comically old file.
On December 21st, 1677, a significant historical event was the siege of Cambrai, which was part of the ongoing Franco-Dutch war, where the French forces were laying siege to the city of Cambrai in the present-day northern France. I hope this helps...
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.
Microsoft made a kernel that best supports an objective workflow, and has basically no limits, and then forced it to basically emulate Windows 95
The question of the oldest currently preserved file with a timestamp attached that can survive a theoretical file system conversion (or a series of) up to a modern OS on modern hardware would be more interesting imo.
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.
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.
It makes sense that Apple also uses the Unix Epoch, as it's also Unix. It's a fork of FreeBSD
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.
Thanks for this. As a kid, I once downloaded Kaillera for netplay, and the DLL claimed to be from 1633. I now finally know why the hell that was even possible.
Weirdly enough, on iPad and iPhone the minimum is January 1st 0001 at 12:00 AM
The maximum is also December 31st 4000 at 11:59 PM
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.
Was really hoping this was some experiment transferring some old digital file onto a modern computer
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?
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
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.
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
@@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.
@@petersilva037 but filesystems didn't
It's about time.
Close enough. Welcome back, Science Elf.
I'm so happy the Tom Scott videos are still being referenced
Setting dates/times of original creation of something digitized, such as a photo, a vinyl record, or a cassette tape, is what meta data is for. The time stamps in the file system are intended only to record file creation, modification, access, etc., via the file system. Meta data is data used to record specific relevant information about file contents. This is information like the type of data contained in the file, the date a photo was taken, camera model used, an album title, song name, the author of the document, etc. The only thing that matters with file date/time stamps is consistency within the file system. And the operating system converts to/from it's own time/date representation by different amounts with different file systems the operating system knows how to access the contents of.
A folder of pictures of Josh Hutcherson is so real lmao
That Discordian calendar censorship
It makes sense that MacOS uses the UNIX epoch, since it uses UNIX as its foundation.
4:08 how did you know
I was just about to ask the same question
HOWWW????
Glad I could finally learn the half life of my Minecraft mods folder
We couldn't figure out that the year was going to roll over in 2000 but by damn we'll go back to the 1700s and just in case you need to read some weaving loom punch cards
Every 100 years a leap year is skipped unless the year is divisible by 400. So the gregorian cycle is from 1601-2000 and then 2001-2400 etc. Therefore Microsoft decided to include the entire previous cycle to make the formula of calculating the actual date easier. the article was referencing adoption not the actual cycle time. I am kind of surprised someone at microsoft was thinking this far ahead but it is very valid.
1601 was chosen because it was a 400-year leap year cycle (No leap year every 100 years, but a leap year every 400)
wtf is going on with mac
they will say this is innovation and use this as a reason to charge you another 200 bucks
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.
1677 on Mac is just as good as 1601 on Windows because Mac is more time efficient. 💁
question of the century
@@CharleyWright-w1yfinally, an actual nuanced answer. Not some dumb overused jokes
2:41 January 1st, 1601 is not arbitrary. It is the first day of the 17th century.
The first day of the 5th gregorian cycle.
*March 25th, 1601
Great video very well explained
11:53: "Linux is perfect and can do no wrong"
Note that the file date for the portable FAT system cannot be before Jan 1, 1980. This is the same default time that early DOS systems without a clock battery used.
NTFS was based on a mix of FAT and some unix and VMS concepts, which explains the weirdness.
And the Apple system is Unix-like under the hood, but some parts of the file system are based on the pre-OSX Mac OS, which, again, explains the weirdness.
Both Windows and Mac OS have some backwards compatibility dependencies on non-extensible bit-sliced dates in older filesystems. The filesystem itself may use a signed integer based on the Unix Epoch, but the libraries for accessing the dates may do some weird conversions.
Linux is more sane because Unix always used a signed integer for all dates and times. Extending that to 64 bit is simple.
If you want to see some dare weirdness, look at mainframe operating systems written when every byte was expensive, but hex dumps on paper needed to be human readable. You have dates in BCD format often leaving out centuries - 1987 would be encoded as C8 C7 (and after a Y2K conversion, possibly 98 C7 as a 3 digit packed decimal)
You know I was half worried to find out that some computer types have a built-in file kill code after a certain date
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.
Now I wonder how old can a file be legitimately. No date editing, like, when was the first file that can be taken to something like windows and see the date
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.
The cycles of the Gregorian calendar are, by my understanding, just a happy accident. Any span of 400 consecutive years within the Gregorian calendar will be exactly 146 097 d = 20 871 wk.
Had they chosen 1600, it would be offset from how we count centuries, which are the way they are because there is no year 0, as it goes 3 BC, 2 BC, 1 BC, 1 AD, 2 AD, 3 AD, etc.
This video is epoch!
Ok that's cool but now the next question is: What is the oldest possible digital file that was ACTUALLY written on the stamped date, preserved, and can still be recognized by modern computers? Somthing written by the ibm 704? The UNIVAC I? The manchester baby? Hell we could even have an entire philosophical discussion as to what even counts as a comouter file. Like if we connect a record player to a computer it can read them. Would that make the first vinyl record also the first comouter file? Would be an absolutely fascinating video
The Unix timestamp is not actually the number of seconds since the epoch; it's the number of seconds less leap seconds. Leap seconds are not counted.
I thought this was going to be about how long data can last on a usb or some sort of hard drive until it’s corrupt
That's the oldest date you can set a file to, not the oldest actual file. According to Wikipedia, looms used data stored on paper tape as early as 1725, so the oldest actual data file stored on digital media is probably around 1725.
Re: macOS, it'd be interesting to see whether those mismatches between the POSIX parts of macOS and the Cocoa parts of macOS originate in OpenStep (where Cocoa has its roots in) or classic Mac OS via Carbon. I imagine they're at least partly the same as how many of Win32's warts were down to making sure that it'd be easy for Win16 programmers to transition their skills over.
“Why 1601 and not 1600?” Probably because it’s easier to measure from the beginning of a century rather than the new year of the last year of the century, lol.
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.
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.
1949 can be Y2K problem, because one of workarounds was to treat dates >=50 as 19xx and
In the Gregorian calendar:
- a year divisible by 4 has a February 29th;
- except a year divisible by 100 does not have a February 29th;
- except a year divisible by 400 has a February 29th.
1600 is divisible by 400 and had a February 29th. This is why 1601 is the start of the current 400 year cycle.
1900 did not have a February 29th, and 2000 had one. By starting Mac OS at 1904, Apple would not need to think about all the conditions of the Gregorian calendar until 2100, the next year divisible by 100 which does not have a February 29th.
Windows has two time kinds: System time and file time. The Windows API has a function called SystemTimeToFileTime that converts one into the other. This is where the inconvenience comes from. Everyone that had to deal with Windows files has come across this annoying thing. One starts in 1601, the other one in the 1980s. It's documented pretty well also.
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