#time_t

[asspull3x]

To time_t or not to time_t, that's the tea

Considering the real time clock on the Asspull IIIx runs at an offset from the host's reported time and defaults to January 1 1984 (you're supposed to reset it), and considering this is the only 64-bit register on the system... I wonder if that's worth the effort?

GCC actually has to pull in some extra support routines just to let the time functions handle such a large value.

If I make its time_t 32-bit it'll cut its range, but it'll look more contemporary and simplifies the compiled code.

Yes, I did ask the same thing on Mastodon. It was pretty nearly a 50/50 split. But I feel like I might get a bigger audience on Tumblr (especially if @foone helps out) and I'm curious.

[zundamonnn]

good morning bracil good morning cairo egypt time is now time_t now; time(&now); std::cout << "Current time: " << now << " seconds since the Unix epoch" << std::endl; go suck on berry kid

[nixcraft]

Oh boy here we go again with 32 bit signed int time_t problem. This is a real problem. Unix is embedded in lots of stuff that doesn't update. We will have real issues with those systems

[cerulity]

Y2K38 will be a much bigger problem than Y2K. One example is with C code. I can almost guarantee you that `int epoch = time(NULL);` is a line in WAY too many codebases. And even if time_t is used, there are so many systems that are 32-bit, so their time_t is usually 32 bits anyways.

[kawaoneechan]

Just watched the latest Hunter R. video about bugs in the original Animal Crossing, and one segment stood out to me.

The Harvest Moon.

Long story short, they precalculated a list of dates spanning from 2001 to 2030, to simplify figuring out when the Harvest Moon should occur. The bug is that they did it wrong and in several years (including this year) the event is off by one or more days.

That's the only yearly event that has such a list in the entire game too, and Hunter considers it the likeliest reason AC is capped at 2030.

The worst part is that nineteen years later, New Horizons only made it worse.

ACNH has several holidays and other such events that don't fall on a particular fixed Gregorian calendar day. Therefore, its table of holidays and events has sixty columns for fancy events' days and another sixty for the months. It supports a range from 2000 (mind you it came out in 2020) to 2060, at which point the game will complain.

(Fun fact: some events like Black Friday are like that and do use the sixty-year timespan but for some reason all sixty are set to November 30. It's described as running from the fourth Friday in November, Thanksgiving being the fourth Thursday, to the end of November, which is what those sixty value pairs are for, but instead they list the end. I know I didn't mis-parse them, too.)

Regardless, when I get around to handling yearly events in Project Special K... I have half a mind to go hard mode and calculate that stuff on startup. Load the event data, find any with special request markers, edit their start and end dates on the spot. Having a generic system would be especially neat so you could specify "fourth Friday in November". In C terms, going from a time_t value to a struct tm does include the day of the week so with enough back and forth and iteration sounds like a good starting point, but there's probably a neater way to do it in standard C++17.

[theprocfilesystem]

Maybe the 2038 time_t overflow will fix me

[datasoong47]

So, I tested this. It'll let you enter a date of 3000 but when I look in the queue it has a date of February 7, 2106 at 00:28 (my timezone - 06:28 UTC)

This appears to be a bug relating to how dates are stored in Unix

Many existing file formats, communications protocols, and application interfaces employ a variant of the Unix time_t date format, storing the number of seconds since the Unix Epoch (midnight UTC, 1 January 1970) as an unsigned 32-bit binary integer. This value will roll over on 7 February 2106 at 06:28:15. That is, at this time the number of seconds since 1 January 1970 is FFFF FFFF in hex.

[auroroboros1]

wqhy my code no compile?

```ifndef stdinclude

define stdinclude iopdfsjopidfspiofjdspiojfds

/stdinclude/

include

include

endif

ifdef DEBUG

define debug printf("your are here %i of %s\ni",line,file)

endif

include

ifndef DEBUG

define debug /do something arbitrary/ int lesbian=0

endif

ifndef random

define random dfklsjladfsjldfslkdfsadfdsklj

/code here/ char* seed(void* gay,void* davoid){int bi=0;while(gay[bi]&&davoid[bi]){ gay[bi]=<<davoid[bi];bi++;};bi=0;/dont do this/while(gay[bi]&&davoid[bi]){davoid[bi]=(char)gay[bi];bi++;};return gay;}; char Random(char* gay,char* trans){char* queer=seed(gay,trans); if (queer[gay[trans[0]]]){return queer[gay[trans[0]]];}; else{return qeueer[random[0]];};}

endif

ifdef random

define unrandom kjadfklskldfsakldfs

char* random(void){return unrandom;}

undef random

endif

int main(int argc;char** argv){ FILE* dykefile=fopen("keysmash","w"0); if(!argv[1]){printf("give me /arguements dumbass/\n";);return argc;} if(!fopen(argv[1],"w")){printf("error opening file: /argv[1]/\n";return argc);} FILE* fagfile=fopen(argv[1],"r");char dyke;char fag;time_t Time; while(!feof(fagfile)){/ignore all that shit and just use libc/ time(Time); srand(Time); dyke=fgetc(fagfile);fag=dyke|rand();fputc(fag,dykefile); } return 666;}

```

[ubuntu-server]

Bringing 12-year LTS to 32-bit Arm processors as CRA comes into force

With the release of Ubuntu 24.04 LTS (Noble Numbat) and Ubuntu Core 24, Canonical introduced a 12-year Long Term Support commitment for 32-bit Arm® processors, addressing the critical time_t overflow issue, commonly known as the “Year 2038 problem.” These processors, essential for critical IoT devices requiring a smaller DRAM footprint and optimised cache usage, can now benefit from long-term…

[hackernewsrobot]

The perils of transition to 64-bit time_t

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/

[cerulity]

Common Things Vulnerable to Y2K38 (+ Explanation)

I want to compile a list of things I find that are vulnerable to the Y2K38 bug. If you find any I don't know about, I can add them to the list. But first, an explanation...

What is Y2K38?

For those that aren't aware, past January 19, 2038 at 3:14:07 UTC (2038-01-19T03:14:07Z), the number of seconds since midnight of January 1, 1970 (1970-01-01T00:00:00Z) will surpass 2^31 - 1.

So what are the implications of this? It has to do with how computers store time.

The Unix epoch is defined as the number of seconds since January 1, 1970, and this is universal to both Unix and Windows systems (so virtually every single computer that doesn't have a homemade operating system). The issue is what specific types of numbers are used to store the epoch.

There are two properties to an integer type: size and sign. The size dictates how many bits a number can hold, and the sign dictates whether or not the integer can store negative numbers. If the number is unsigned, it will be able to store numbers ranging from zero to 2^n - 1, where n is the size of the integer in bits. This means that an 8-bit unsigned number can hold numbers ranging from 0 to 255, because 2^8 - 1 is 255. If a number is signed, the positive range is cut in half. Signed numbers range from -2^(n - 1) to 2^(n - 1) - 1. This means that an 8-bit signed integer can hold numbers ranging from -128 to 127, as -2^7 is -128, and 2^7 - 1 is 127. As integers are used to store the Unix epoch, this means that the epoch is limited to the range of the integer type you use to store it.

If you decide to use a 32-bit signed integer to store the Unix epoch, then once the epoch reaches 2^31 - 1 (which is the upper limit of 32-bit signed integers and is around 2.1 billion), the epoch won't be able to increase anymore. So what happens when we try to increase it anyways? We get an integer overflow.

Due to how CPUs add numbers together, when the result of an operation is larger than the range of the integer type, the result is wrapped around. For example, if you have the number 127 in an 8-bit signed integer, adding one will wrap around to -128! This is a problem for the epoch, because now, instead of storing 2.1 billion seconds past January 1, 1970, it will now be storing 2.1 billion seconds before 1970, which goes all the way back to December 1901!

So why not just use a bigger number? Well, it's not really that simple. There has been an effort to switch over to 64-bit integers, which has an overwhelmingly generous range of around 21 times the estimated age of the universe. However, there are some systems that just can't change or haven't changed for a variety of reasons, and this is what the list will be about. There are two main causes for the Y2K38 bug, and most vulnerabilities stem from them:

32-bit representation of of time_t: time_t is the integer type that time is stored in. When a C program calls the time() function, it will receive a time_t. If time_t is 32-bits long, then the time() function will be vulnerable.

Downcasting the result of time(): There's a pattern in programming I like to call "int-defaultness". C's primitive types are not named with sizes. Instead, they are called 'char', 'short', 'int', and 'long'. These types are standardised to be at least 8 bits, 16 bits, 32 bits, and 64 bits respectively, but most platforms just use those sizes exactly. Usually, you would use exact-sized types like int16_t, uint64_t, and so on, or if it's a function like time(), you would use time_t. However, it is a common pattern to default to int as an integer type, and someone who isn't careful may just convert the result of the time() function into an int. This is known as downcasting, which is the conversion from one integer type to a smaller one. Regardless of whether or not time_t is 32 bits or 64 bits, this downcast will always convert the time to 32 bits, and the overflow behaviour will apply, leaving PHP vulnerable.

As you can see, the time() function is the root cause of the bug, and due to its popularity, usages and mimics of time() can be left vulnerable.

So, without further ado, here is...

The List of Vulnerabilities

PHP time() function: PHP has a time() function that acts very similar to C's, and if the size of a PHP int is 32 bits, PHP is left vulnerable.

pcap file format: The pcap file format (used by libpcap, which is used by utilities like tcpdump and Wireshark) is a format for storing captured packets, and the specification states that the timestamps of packets must stored in a 32-bit unsigned integer. Luckily, since it is unsigned, this will overflow in the year 2106, but there is still some vulnerability here. The PcapNG file format uses 64-bit timestamps, which prevents the vulnerability.

Embedded systems: Smaller computers have a tendency towards lower bit-widths, and 32 bits is common. Embedded systems control things like radios, elevators, GPSes, and more things that don't require heaps of computation power. These systems commonly define time_t to be 32 bits, making them vulnerable.