>writing code involving timestamps >use 32 bit int

>>61929907
when will it overflow at 32 bit?

>his language isn't smart enough to increase to the next largest data type upon evaluation

>>61930064
that's not smart. what if you're trying to save memory

>>61929907
d e v i l i s h

>>61930064
that's not smart. what if you're trying to save processing power by not checking for overflows constantly

>>61929922
at 03:14:08 UTC on 19 January 2038

$ cat /usr/include/sys/_types.h | grep time_t
typedef __int64_t       __time_t;       /* epoch time */

no really, just use a fucking time_t and recompile your software once Linux stops being obsolete

>implying we'll make it to the 2030s

File: DG8i10-XkAAPSDR.jpg (47KB, 924x439px) Image search: [Google]

47KB, 924x439px

>>61932399
> implying

@echo off
set year=2038
set day=19
set m=1
:lel
title %day%/%m%/%year%
set /a day+=1
if "%day%"=="31" set /a m+=1&set day=1
if "%m%"=="13" set /a year+=1&set m=1
goto lel

>>61932293
>using cat | grep

>>61930122
I do not think people in 2030s will care much about memory.(unless webapps become the norm)

>>61930122

this is 2017 not 1985

>>61929907
>writing safety-critical code using 64-timestamps
>mfw it stops working after 150 years

>>61934976
> 64-bit signed time_t expands the times representable by approximately 293 billion years in both directions, which is over twenty times the present age of the universe per direction.
try again

>>61932242
Why the fuck are using a signed 32 bit int fag?

>>61935552
nanosecond precision timestamps
you tech illiterate

File: 1422415904757.jpg (21KB, 338x332px) Image search: [Google]

21KB, 338x332px

>not storing dates as strings in YYY-MM-DD-hh-mm-ss format

just keep adding precision until you get it the way you like it