moment.utc(string)は、タイムゾーンが欠落している場合、ISO8601を現地時間として解析します
これはISO8601が言う方法です...そしてEcmaScript6
これはmoment(string)
も当てはまると思いますが、 moment.utc(string)
を使用する場合は、UTCとして解析する必要があると思います。
moment('2010-10-20T08:40'); // should parse to local time
moment.utc('2010-10-20T08:40'); // should parse to utc time
私は問題を抱えています、私はこれに関連していると思います:
この日付を2012年12月4日(DD-MM-YYYY、UTC)にUnixタイムスタンプに変換しようとしています。
私はこれをやっています:
var date = '12-04-2012';
var mm = moment().utc( date, "DD-MM-YYYY" );
console.log( mm.valueOf() );
これにより、誤ったタイムスタンプが出力されます: 1334670827391
。
私が試してみると:
console.log( mm.format('DD-MM-YYYY') );
それはアウトパス: 17-04-2012
a538306はこれを修正します。 1.6.0で出ます
最新バージョンでもこの問題が発生しています。
渡しています:moment.utc( '2012-12-14T00:29:40.276Z')および取得:{_ d:2012年12月13日木曜日18:29:40 GMT-0600(中部標準時)、_ isUTC:true (2012年12月13日木曜日18:29:40 GMT-0600(中部標準時)).. utc時間ではなく、私のローカルタイムゾーンを使用しています。
これは私が1.7.2
得ているものです。
moment.utc('2012-12-14T00:29:40.276Z').format(); // "2012-12-14T00:29:40+00:00"
Chromeでコンソールに書き込むと、次のようになります(最新バージョン)。
console.log(moment.utc( '2012-12-14T00:29:40.276Z'));
console.log(moment.utc( '2012-12-14T00:29:40.276Z')。format());
console.log(moment.utc( '2012-12-14T00:29:40.276Z')。toDate());
H {_d:2012年12月13日木曜日18:29:40 GMT-0600(中部標準時)、_ isUTC:true、_a:Array [8]、_ lang:false、clone:function…}
2012-12-14T00:29:40 + 00:00
2012年12月13日木曜日18:29:40GMT-0600(中部標準時)
UTC(タイムゾーンなし)で新しい日付を作成するべきではありませんか? また、最初のconsole.logには、UTC時間ではなく、CSTタイムゾーンのモーメントオブジェクトが表示されます。
Thu Dec 13 2012 18:29:40 GMT-0600
は、実際には2012-12-14T00:29:40.276Z
とまったく同じ時間です。 それらは、同じ時間を表示するための異なる方法です。 必要に応じて、次の手順でこれを確認できます。
console.log(moment.utc('2012-12-14T00:29:40.276Z').toDate().toString());
// Thu Dec 13 2012 16:29:40 GMT-0800 (PST)
console.log(moment.utc('2012-12-14T00:29:40.276Z').toDate().toUTCString());
// Fri, 14 Dec 2012 00:29:40 GMT
ネイティブJS Date
はUTC vsローカルモードがなく、 getUTCHours
やgetHours
ようなアクセサーがあります。
Moment.jsは、utcモードとローカルモードの概念を使用して、これらのgetUTC*
とget*
メソッドを抽象化します。 モーメントがUTCモードの場合、 getUTC*
メソッドを使用します。 ローカルモードの場合は、 get*
メソッドを使用します。
明確化してくれてありがとう。
私は、iso標準が、ZがデフォルトでUTCになるタイムゾーンがないことを意味すると述べていることを期待して考えていました。 したがって、moment.utc( '2012-12-14T00:29:40.276Z')またはmoment( '2012-12-14T00:29:40.276Z')を実行した場合、両方ともutcとして扱われ、utcフラグは次のようになります。 trueに設定します。
PS、ご迷惑をおかけして申し訳ありません:。 私は別の質問のために新しいディスカッションを作成しています:s
問題ない。
moment()
とmoment.utc()
両方でisUTC
フラグを設定しない理由は、UTC + 0文字列を解析している場合でも、を表示したい場合があるためです。ユーザーのタイムゾーンでの瞬間。
これはかなり一般的な使用例です。時間をバックエンドにISO8601UTC + 0文字列として保存し、ユーザーのタイムゾーンでフロントエンドに表示することをお勧めします。
おかげで、他の誰かがこの議論も役立つと思うことを願っています。
console.log(moment.utc())を実行すると、「Fri Jan 18 2013 16:25:32 GMT-0800(UTC)」と報告されますが、これは太平洋標準時であり、現在のUTC時間ではありません。 ログに記録すると明示的に(UTC)と表示されるので、「16:25:32」はUTC時間であると思われますが、実際には太平洋時間です...
さらに、moment.utc()。valueOf()がエポックからUTCでミリ秒数を返していると想定していますが、これは正しくないようです。 この動作を見たことがありますか?
console.log(moment())
H {_d:2013年1月18日金曜日16:51:20 GMT-0800(UTC)、_ isUTC:false、_a:null、_lang:false}
console.log(moment.utc())
H {_d:2013年1月18日金曜日16:51:20 GMT-0800(UTC)、_ isUTC:true、_a:null、_lang:false}
_isUTCフラグを反転するだけであるように見えます。 :P .utc()を指定するかどうかに関係なく、現地時間を返しているようです。
はい、 .utc
と.local
は、すべてのゲッターとセッターで使用されている.isUTC
フラグを反転するだけです。
ネイティブのDate.toString
は現地時間で表示されるため、両方のインスタンスで同じ表現が表示されます。
ただし、 .format
は.isUTC
フラグを使用するため、 isUTC
フラグをtrueに設定してモーメントをフォーマットすると、期待どおりにフォーマットされます。
Date.prototype.toString
、 Date.prototype.toUTCString
、およびmoment.fn.format
に関する以下の違いを参照してください。
moment().toDate().toString(); // "Wed Jan 23 2013 09:48:54 GMT-0800 (PST)"
moment.utc().toDate().toString(); // "Wed Jan 23 2013 09:48:54 GMT-0800 (PST)"
moment().toDate().toUTCString(); // "Wed, 23 Jan 2013 17:48:54 GMT"
moment.utc().toDate().toUTCString(); // "Wed, 23 Jan 2013 17:48:54 GMT"
moment().format(); // "2013-01-23T09:48:54-08:00"
moment.utc().format(); // "2013-01-23T17:48:54+00:00"
ここで同じ問題:
moment()。valueOf()およびmoment()。utc()。valueOf()
同じ値を返します! :がっかり:
したがって、UTCミリ秒を取得するには、次のことを行う必要があります。
moment().valueOf() - (moment().utcOffset() * 60 * 1000)
@ rubenspgcavalcante-何を求めているのか
あなたが書いたスニペットは、実際には別の瞬間を返します。
UTCフラグがtrueに設定されているが、format()をcalすると、同様の問題が発生します。 現地時間を返します。 これがスクリーンショットです。
オブジェクトの後の行は、format()を呼び出した後のvarのconsole.logです。 その上に。
私は何か間違ったことをしていますか?
@ james-hoegerl内部の日付オブジェクトは2016年7月5日の19:00中央にあるようです。 UTCに到達するためにそれに5時間を追加すると、ログに記録されているように見えるのは7月6日なので、要するに、何も問題はありません。
fullcalendarを使用しているように見えます。 異常な動作を引き起こす可能性のある瞬間の拡張/モンキーパッチを実行します。
たぶん私はuctについて混乱しているだけです。 「2016-05-0707:00:00」を取得すると、それをDBに保存して、各エンドユーザーコンピューターの現地時間を瞬時に取得できると思いました。
したがって、まず最初に、あなたが6016-07-05(5月7日ではなく7月5日)を意味していると仮定します。 現地時間は7月5日19:00です。 米国中部夏時間に合わせて調整し、5時間を追加します。 これにより、7月6日は深夜になります。
7月5日を取得する場合、実際に必要なのはUTCではなく現地時間だと思います。 その瞬間に.local()を呼び出して、現地時間に戻すことができます。
あなたはこれが役に立つと思うかもしれません: https :
@maggiepintにご協力いただきありがとうございます。 はい、私の前のコメントは7-5を意味しました。 申し訳ありませんが、今週末、プールサイドの携帯電話に急いでコメントを書きました。 私の考えが今どこに逆行しているかがわかります。 fullcalendarは、すべてのあいまいなタイムゾーンのモーメントオブジェクトで機能するので、私はそこで誤解を持っていたので、それについていくつかの調査を行う必要があると思います。 お時間をいただきありがとうございます@maggiepint
こんにちは、UTCをユーザー時間に変換するには、フォーマットを提供する必要がありますか?
例:let utcTime = moment({時間:10、分:20).format( 'YYYY-MM-DD HH:mm:ss');
stillUtc = moment.utc(utcTime).toDate();
localTime = moment(stillUtc).local();
これで、localTImeを取得できます。 しかし、フォーマットを削除しても、UTCフォーマットは可能です。 ここで10:20は、バックエンドからのUTCtimeZoneです。 これをユーザーのタイムゾーンでユーザーに表示したいと思います。
私を助けてください。
ここで同じ問題:
moment()。valueOf()およびmoment()。utc()。valueOf()
同じ値を返します! 😞
したがって、UTCミリ秒を取得するには、次のことを行う必要があります。
moment()。valueOf()-(moment()。utcOffset()* 60 * 1000)
@ rubenspgcavalcante-何を求めているのか
@ mj1856moment ()。valueOf()とmoment()。utc()。valueOf()がどのように同じ値を返すのかわかりませんか?
UTC機能に関する混乱の表現に追加する必要があります。 moment.utc()の最も直感的な期待は、UTC時間で現在の日付/時刻を表すMomentオブジェクトを返すことです。 しかし、この議論によれば、そうではなく、フラグを立てるだけです。 そのフラグが何をするのかはまだ不明です。 これはドキュメントに記載されていないため、ひどく不十分です。 このトピックの説明と例をバックログに追加してください。 ありがとうございました。
最も参考になるコメント
UTC機能に関する混乱の表現に追加する必要があります。 moment.utc()の最も直感的な期待は、UTC時間で現在の日付/時刻を表すMomentオブジェクトを返すことです。 しかし、この議論によれば、そうではなく、フラグを立てるだけです。 そのフラグが何をするのかはまだ不明です。 これはドキュメントに記載されていないため、ひどく不十分です。 このトピックの説明と例をバックログに追加してください。 ありがとうございました。