Skip to main content

reshared this

in reply to Pup Keith DX Director's Cut

グレェ「grey」
グレェ「grey」  
•
OpenBSD already audited and did their best effort to patch all 32-bit related UNIX epoch time bugs in release 5.5 from uhh (checks notes) 2014.

If OpenBSD can be 2038 ready, and they share their source, other projects don't have any excuses if they still suck by then.
in reply to Pup Keith DX Director's Cut

Fuggy 🇮🇱✡️
Fuggy 🇮🇱✡️  
•
why does it stop there and not year 2^32?
in reply to Fuggy 🇮🇱✡️

CyberSpook
CyberSpook  
•
@fuggy
That would actually be year 1970 + 2³² - 1 because the counting starts at 1970. It would make no sense to start at year 1. Frankly, that's not how internal clocks work anyway, I think they all start at that exact year and that's the joke.
@keith
@Pup Keith DX Director's Cut @Fuggy 🇮🇱✡️
in reply to CyberSpook

CyberSpook
CyberSpook  
•
@fuggy
And yeah, you wouldn't reach year 2³² anyway because 32 bits can only display numbers up to 2³² - 1 (11111111111111111111111111111111), after which you get an overflow.
@keith
@Pup Keith DX Director's Cut @Fuggy 🇮🇱✡️
in reply to Pup Keith DX Director's Cut

logan :PoweredByGentooBadge: :coffeemug2:
logan :PoweredByGentooBadge: :coffeemug2:  
•
I have no idea why this information isn't a struct...
```
typedef struct {uint64_t Year,Month,Day,Hour,Minute,Second;} DateTime_st;
``` #🤔#🤔
in reply to logan :PoweredByGentooBadge: :coffeemug2:

Pup Keith DX Director's Cut
Pup Keith DX Director's Cut  
@logan because with that you can't just tick a seconds counter up, or get the duration between timestamps by subtracting two numbers. Unix time is actually pretty good, as it means programs don't have to deal with the semantics of (insert current locale's calendar system) until they actually need to display a time to the user
@logan :PoweredByGentooBadge: :coffeemug2:
in reply to Pup Keith DX Director's Cut

Lena 🝖
Lena 🝖  
•
Not to be a pedant, but if the integer is signed, wouldn't it wrap back to 1901-12-13?
⇧