# 1234567890



## Rakiao (Feb 13, 2009)

NOOOOOOOOOOOOOOOOOO! Its the end of the (linux/unix) world! WE ARE ALL GOING TO DIE! 

LOL​


----------



## Pi (Feb 13, 2009)

Rakiao said:


> NOOOOOOOOOOOOOOOOOO! Its the end of the (linux/unix) world! WE ARE ALL GOING TO DIE!
> 
> LOL​



no, the end of the world is Mon Jan 18 20:14:07 2038, or 2147483647, or 2**31-1.


----------



## net-cat (Feb 13, 2009)

Pi said:


> no, the end of the world is Mon Jan 18 20:14:07 2038, or 2147483647, or 2**31-1.


Quick! Everyone switch to 64-bit! Or at least unsigned integers!


----------



## Pi (Feb 13, 2009)

net-cat said:


> Quick! Everyone switch to 64-bit! Or at least unsigned integers!



Speaking of, NetBSD merged in 64-bit time_t recently.


----------



## net-cat (Feb 13, 2009)

Oh, really? That's pretty cool.

I'd be interested to see how apps that assume it's 32-bit break now.


----------



## ToeClaws (Feb 13, 2009)

net-cat said:


> Quick! Everyone switch to 64-bit! Or at least unsigned integers!



*laughs* I can't help but see a bunch of geeks (like us) waving around signs that say that instead of the usual "Repent!" lol


----------



## Rakiao (Feb 13, 2009)

lol, its fun to be a geek.


----------



## Pi (Feb 14, 2009)

net-cat said:


> Oh, really? That's pretty cool.
> 
> I'd be interested to see how apps that assume it's 32-bit break now.



Binaries pre-5.0 will get the 32-bit time_t. A recompile brings everything into the 64-bit world.

Interchanging data between them will probably be dicey at first, but hey, that's the price you pay for progress.


----------



## Koda (Feb 14, 2009)

net-cat said:


> Quick! Everyone switch to 64-bit! Or at least unsigned integers!



Lol windows already does that


----------



## net-cat (Feb 14, 2009)

Koda said:


> Lol windows already does that


Does what?


----------



## Pi (Feb 15, 2009)

net-cat said:


> Does what?




```
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp>copy con: test.c
#include <time.h>
#include <stdio.h>
int main(int argc, char* argv[]) {
    printf("time_t is %d bytes, or %d bits\n", sizeof(time_t), sizeof(time_t)*8);
    return(0);
}
^Z
        1 file(s) copied.

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp>cl test.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 8.00.50727.42
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:test.exe
test.obj

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp>test.exe
time_t is 8 bytes, or 64 bits
```


----------



## Koda (Feb 15, 2009)

net-cat said:


> Does what?



Has been using 64-bit timestamps since the mid-90s.

Their 'apocalypse' is set to be in the year 60000 or something XD


----------



## net-cat (Feb 15, 2009)

Oh, cool. I didn't know that.


----------



## Koda (Feb 15, 2009)

Hehe.. Interestingly enough, while they have years WAAAAAY out into the future, their 'epoch' was in 1601 

I think Unix's epoch was 1969


----------



## Pi (Feb 15, 2009)

Koda said:


> Hehe.. Interestingly enough, while they have years WAAAAAY out into the future, their 'epoch' was in 1601
> 
> I think Unix's epoch was 1969



Uh, for hysterical raisins, any of the UNIX-related time functions that use time_t have their epoch at Jan 1 1970, 0:00 GMT.


----------



## Koda (Feb 15, 2009)

Sh*t. I chose the down side of the second. See, there's and up side and a down side to every second.


----------



## Pi (Feb 15, 2009)

Koda said:


> Sh*t. I chose the down side of the second. See, there's and up side and a down side to every second.



That isn't what I meant, though. Do you have a source for the Windows epoch being in the 1600s? As far as I remember, that is not correct.


----------



## CyberFoxx (Feb 15, 2009)

```
cyberfoxx@sally src $ uname -a
Linux sally 2.6.28-gentoo #2 PREEMPT Sat Feb 14 09:49:24 EST 2009 x86_64 Intel(R) Celeron(R) D CPU 3.46GHz GenuineIntel GNU/Linux
cyberfoxx@sally src $ gcc time.c -o time
time.c: In function 'main':
time.c:4: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
time.c:4: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
cyberfoxx@sally src $ ./time
time_t is 8 bytes, or 64 bits
cyberfoxx@sally src $
```
Mind you, it's still 32-bit on my PPC and x86 boxes. There's supposed to be a fix getting merged into glibc sometime, just not sure when. Then again, by 2038, most people should be using at least a 64-bit system anyway.


----------



## Koda (Feb 15, 2009)

Wikipedia appears to agree with me. http://en.wikipedia.org/wiki/NTFS


----------



## Pi (Feb 16, 2009)

Huh! That's interesting. I guess I've only ever used the libc functions for time.


----------



## Koda (Feb 16, 2009)

I think the MSSQL database uses the same type of timestamps, because I remember a 'new' datetime object defaults to 1601. One thing that bugs me with .NET is the fact that in the database, a datetime column can be null, but in code, datetime is a non-nullable type, gotta use that weird ? operator. 

Now if only I could get my VCR to stop defaulting to 2001!


----------



## net-cat (Feb 16, 2009)

Huh. Interesting...


```
douglas@beryllium:~$ gcc time_t.c
time_t.c: In function â€˜mainâ€™:
time_t.c:5: warning: format â€˜%dâ€™ expects type â€˜intâ€™, but argument 2 has type â€˜long unsigned intâ€™
time_t.c:5: warning: format â€˜%dâ€™ expects type â€˜intâ€™, but argument 3 has type â€˜long unsigned intâ€™
douglas@beryllium:~$ ./a.out 
time_t is 8 bytes, or 64 bits
douglas@beryllium:~$ uname -sm
Linux x86_64
douglas@beryllium:~$
```


```
[douglas@feline ~]% gcc time_t.c
[douglas@feline ~]% ./a.out     
time_t is 4 bytes, or 32 bits
[douglas@feline ~]% uname -sm   
FreeBSD i386
[douglas@feline ~]%
```


----------

