Unix zaman damgası olarak depolanmış tarihlerimiz var. Bir kullanıcının belirli bir tarih aramasına izin vermek için - saat dilimi ayarına bağlı olarak, "2012-05-03" için bir aramanın önceki/sonraki sonuçları bulamadığından emin olmak için bu zaman damgasını sorguya dönüştürüyorduk Kullanıcının hangi saat dilimine bağlı olduğuna bağlı olarak. 2038-01-19'dan sonra MySQL from_unixtime?
yani bir tarih uygun zaman dilimi bu girdiyi bulmalı2012-05-04
ararken Burada karşılıklı
2012-05-03 23:00 (UTC)
gibi bir kullanıcı saklanır eğer.
Bu
anda böyle yapılır:CONVERT_TZ(FROM_UNIXTIME(`javaTimeStampColumn`/1000),'+00:00','+00:00')
ofc. ofsetler, kullanıcı saatine bağlı olarak ayarlanır.
Şu anda karşı karşıya olduğumuz sorun: Java, 2038
tarihinden sonraki tarihleri unix zaman damgası olarak başarılı bir şekilde depolar. MySQL yöntemi from_unixtime
ancak nedeniyle bu kadar tam sayı tipi sınırlama 2147483647
daha yüksek değerlerin herhangi bir dönüştürme desteklemez:
SELECT FROM_UNIXTIME(2147483647); //2038-01-19 04:14:07
SELECT FROM_UNIXTIME(2147483648); //null
MySQL sunucusu kendisi 64 bit, ancak ofc olup. FROM_UNIXTIME
uzun argümanı kabul etmelidir.
Şu anda uygun bir yedek bulamıyorum, herhangi bir ipucu var mı?
Biz olabiliriz. zaman damgası bir Uzun olarak yükleyin ve uygulamada ele alın - Ancak lazylaoding için sorgulama sırasında doğru şekilde dönüştürebilmemiz gerekir.
Veri türünü "datetime" olarak değiştirmemek için herhangi bir sebep var mı? –
@juergend Evet, ne yazık ki veriler, bunu değiştiremeyeceğimiz bir uygulama tarafından oluşturulmaktadır. (3. taraf kitaplığı) – dognose
Zaman damgası sütununun veri türünü "bigint" olarak değiştirmeyi denediniz mi? –