Typ pola PostgreSQL dla znacznika czasu unix?

Question

PostgreSQL typ pola dla Unix timestamp:

• przechowywać go jako znacznik czasu Uniksa
• pobrać go jako znacznik czasu Uniksa, jak również.

Przeszedłem przez Date/Time Types ^{postgreSQL V 9.1}.

---

• Czy całkowitą najlepszym sposobem, aby przejść !? (To, co zrobiłem, kiedy byłem przy użyciu MySQL. Użył int(10))

Answer 1

całkowitej byłoby dobre, ale nie na tyle dobre, ponieważ nie obsługuje PostgreSQL niepodpisanych typów

Answer 2

ja po prostu iść z użyciem datownik z (wy) TIME ZONE i używać EXTRACT aby uzyskać reprezentację uniksowy znacznik czasu, gdy zajdzie taka potrzeba .

Porównaj

SELECT NOW(); 

z

SELECT EXTRACT(EPOCH FROM NOW()); 

Answer 3

Nie rozumiem, dlaczego ma pytanie niektóre negatywne głosy.

W każdym razie znalazłem stronę closely related question na stronie Administratorzy baz danych (z wieloma pozytywnymi głosami).

To tylko sugeruje, aby tam spojrzeć, ponieważ istnieje dużo pełniejsza informacja na temat tego nietrywialnego tematu.

Answer 4

Znacznik czasu unix epoki (2014-04-09) to 1397071518. Potrzebny jest więc typ danych, który będzie w stanie zapisać liczbę przynajmniej tak dużą.

Jakie typy danych są dostępne?

Jeśli odnieść się do PostgreSQL documentation on numeric types znajdziesz następujące opcje:

Name  Size  Minimum    Maximum 
smallint 2 bytes -32768    +32767 
integer 4 bytes -2147483648   +2147483647 
bigint 8 bytes -9223372036854775808 +9223372036854775807 

Co to znaczy jeśli chodzi o reprezentację czasu?

Teraz możemy wziąć te numery i przekształcania ich w terminach przy użyciu epoch converter:

Name  Size  Minimum Date  Maximum Date 
smallint 2 bytes 1969-12-31  1970-01-01 
integer 4 bytes 1901-12-13  2038-01-18 
bigint 8 bytes -292275055-05-16 292278994-08-17 

Zauważ, że w ostatniej instancji, stosując sekund stawia się tak daleko w przeszłość i przyszłość, że prawdopodobnie nie ma znaczenia. Rezultat, który podałem jest dla reprezentacji epoki unixowej w milisekundach.

Czego się nauczyliśmy?

1. smallint to zdecydowanie zły wybór.
2. integer to przyzwoity wybór w tej chwili, ale twoje oprogramowanie będzie wybuchać w roku 2038. Apokalipsa Y2K nie ma nic na Year 2038 Problem.
3. Korzystanie z bigint jest najlepszym wyborem. Jest to rozwiązanie przyszłościowe wbrew najbardziej prawdopodobnym potrzebom ludzkim, choć może ono być jeszcze: the Doctor.

Możesz, ale nie musisz zastanowić się, czy nie warto przechowywać datownika w innym formacie, takim jak standard ISO 8601.