私の新しい職場では、それらは多くの日付を「エポックからの日数」（以下、DSEと呼びます）として表しています。JavaScriptがDSEからエポック（UNIXタイムスタンプ）からの秒数に変換する際に問題が発生しています。変換を行うための私の関数は次のとおりです。
function daysToTimestamp(days) {
return Math.round(+days * 86400);
}
例として、私が13878を通過すると（これは2008年1月1日を表すと予想されます）、私が期待する1199098800ではなく、1199059200に戻ります。なんで？
1199059200は、UTCで2007年12月31日を表します。サンプルPythonセッション：
>>> import time
>>> time.gmtime(1199059200)
(2007, 12, 31, 0, 0, 0, 0, 365, 0)
すべてのtime_t値がUTCに反していることに注意してください。:-)タイムゾーンに応じて調整する必要があります。
編集：あなたと私は両方ともニュージーランドにいるので、1199098800の値を取得した方法は次のとおりです。
>>> time.localtime(1199098800)
(2008, 1, 1, 0, 0, 0, 1, 1, 1)
これは、新年（ニュージーランドの夏）のタイムゾーンが+1300であるためです。数学をして見てください。:-)
UTCでの2008年1月1日の場合、86400を1199059200に追加し、1199145600を取得します。
>>> time.gmtime(1199145600)
(2008, 1, 1, 0, 0, 0, 1, 1, 0)
これは、時刻がUTCであるため、時間の線形表現でもUTCの真の表現でもないためです（両方とも間違われることがよくあります）が、UTCうるう秒を表す方法がありません。
Unix時間（time_t）は、1970年1月1日からのミリ秒ではなく秒で表されます。
あなたが見ているのはタイムゾーンの違いだと思います。あなたが持っているデルタは11時間ですが、どのようにして期待値を取得していますか？
1199098800/86400 = 13878.4583333333333 (3 が永遠に繰り返される) であるため、13878.0 ではありません。整数として格納されているため、13878.0 に丸められます。それがもたらす違いを確認したい場合は、これを試してください: .4583333333333*86400 = 39599.99999999712. それでも少し間違っていますが、これが 1199098800-1199059200=35600 のような不一致の原因です。
86400000を掛ける必要があります
1日=24時間*60分*60秒*1000ミリ秒=86400000