[totoo]

Hej

Jag sitter på en skitkass mobiluppkoppling och har jättesvårt att hårdtesta en massa olika timestamps, därför frågar jag om man behöver en unsigned int för att lagra dessa. Jag har alltid kört unsigned, men på en nystartad site lagrar jag medlemmars födelsedatum med ett sånt timestamp (för att det tar lite plats) och fick en felrapport pga att unsigned inte fungerar för dem födda innan 1970 - såklart (eftersom alla negativa värden blir out of range).

Kan jag göra den signed utan att riskera nåt?

Tack

MVH Tobbe

[grazzy]

Vad är felet på datetime som lagras som integer internt?

[totoo]

Det är nog inga fel på den, men jag har alltid använt och lagrat unix timestamp i sitt grundformat. Men det är inte aktuellt att ändra datatyp (mer än signed/unsigned) just nu, för det har säkert en massa konsekvenser som betyder mer jobb.

Sååå, måste den vara unsigned för att klara datum +- 100 år från idag?

[grazzy]

Japp.. det är iaf vad jag körde med innan jag såg ljuset.

[Jonas]

date, time & datetime är optimalt för datum & tid.

grazzy har rätt, och jag håller med honom, har man sett ljuset så följer man det. Innan dess så fumlade man i mörkret och det är det du gör just nu.

[totoo]

Hmm... Det är optimalt förutsatt att man använder mysqls funktioner för datum och tid antar jag? Vad kan annars vara mer optimalt än en integer?

Men sure, finns det något bra knep från phpmyadmin att omvandla allt från unix timestamp till date? Vågar inte bara byta typ, för då ramlar säkert allt i bitar.

Tack

[eg0master]

Skapa en ny kolumn av datetime typ. Uppdatera den mha ditt unix timestamp mha MySQL funktionen FROM_UNIXTIME. ta bort din gamla unix timestamp kolumn.

http://dev.mysql.com/doc/refman/6.0/en/dat...n_from-unixtime

[totoo]

Originally posted by eg0master@Jul 13 2008, 23:14
Skapa en ny kolumn av datetime typ. Uppdatera den mha ditt unix timestamp mha MySQL funktionen FROM_UNIXTIME. ta bort din gamla unix timestamp kolumn.
http://dev.mysql.com/doc/refman/6.0/en/dat...n_from-unixtime

Hmm, det fungerade när jag satte ett manuellt hårdkodat datum inom FROM_UNIXTIME, men inte med det befintliga timestampfältet.

UPDATE users SET dateOfBirth = FROM_UNIXTIME( birthDay )

MySQL sa:
#1265 - Data truncated for column 'dateOfBirth' at row 6

Troligen pga att birthDay är unsigned va?

F.ö. verkar en vanlig SIGNED INT fungera helt okej för alla födelsedatum till och med om ca 30 år. Det får kanske duga just nu.

Nä nu får det vara nog för ikväll, palla att surfa med 2kb/s

[Jonas]

Kör du tex. en timestamp som tex. NOW() (inom mysql) på en unsigned INT så blir det en int, kör du det på en DATETIME så blir det ett datum med kl. slag. osv. Så egentligen behöver man inte FROM_UNIXTIME().

Min erfarenhet.

[Jine]

Jag gjorde precis ett litet test i mysql.
Skapar man en tabell, med EN rad, EN kolum, med namnet A, sätter type till datetime och pejstar in nuvarande tiden/datumed, blir den raden 9 byte.

Gör man det samma, döper en till B och sätter int(10) så blir den raden 7 byte.

Eftersom negativa tal behöver 1 byte mer (-) så borde du altså spara 1 byte på att använda nån form av negativ funktion av unix_timestamp. (För varje rad)
Om det handlar om en större applikation, eller nån form av loggar, så kommer det alltså innebära att man sparar 1kb, för varje 1 048 576 rad. Är det värt det?

(Det fungerade dock inte att sätta datum under 1970 med vanliga unix_timestamp($DATUM))

// Jim