<p>moment.utc (string) analisa ISO8601 como hora local quando o fuso horário está ausente</p>

Criado em 12 abr. 2012  ·  24Comentários  ·  Fonte: moment/moment

Comentários muito úteis

Devo acrescentar à expressão de confusão em torno da funcionalidade UTC. A expectativa mais intuitiva de moment.utc () seria que ele retornaria um objeto Moment representando a data / hora do now no horário UTC. Mas, de acordo com esta discussão, não é o caso e apenas define a bandeira. Ainda não está claro o que essa bandeira faz. Nada disso é mencionado na documentação, o que a torna terrivelmente inadequada. Por favor, acrescente esclarecimentos sobre este tópico com exemplos para o seu backlog. Obrigado.

Todos 24 comentários

moment.utc (string) analisa ISO8601 como hora local quando o fuso horário está ausente

é assim que diz ISO8601 ... e EcmaScript 6

Acho que se aplica a moment(string) muito bem, mas ao usar moment.utc(string) , acho que a implicação é que você deseja que seja analisado como UTC.

moment('2010-10-20T08:40'); // should parse to local time
moment.utc('2010-10-20T08:40'); // should parse to utc time

Estou tendo um problema, acho que relacionado com isto:

Estou tentando converter esta data: 12-04-2012 (DD-MM-AAAA, em UTC) para seu carimbo de data / hora Unix.
Eu estou fazendo isto:

var date = '12-04-2012';
var mm = moment().utc( date, "DD-MM-YYYY" );
console.log( mm.valueOf() );

Isso gera um carimbo de data / hora incorreto: 1334670827391 .
Se eu tentar:

console.log( mm.format('DD-MM-YYYY') );

Superou: 17-04-2012

a538306 corrige isso. Será lançado em 1.6.0

Ainda estou vendo esse problema na versão mais recente.

Estou transmitindo: moment.utc ('2012-12-14T00: 29: 40.276Z') e recebendo: {_d: Thu Dec 13 2012 18:29:40 GMT-0600 (Central Standard Time), _isUTC: true (Qui, 13 de dezembro de 2012 18:29:40 GMT-0600 (Horário padrão central)) .. Não está usando o horário utc, mas meu fuso horário local.

Isso é o que estou recebendo com 1.7.2 .

moment.utc('2012-12-14T00:29:40.276Z').format(); // "2012-12-14T00:29:40+00:00"

Aqui está o que acontece comigo (versão mais recente) quando escrevo para o console no 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: Qui, 13 de dezembro de 2012 18:29:40 GMT-0600 (Horário padrão central), _isUTC: verdadeiro, _a: Array [8], _lang: falso, clone: ​​função…}

2012-12-14T00: 29: 40 + 00: 00

Qui, 13 de dezembro de 2012 18:29:40 GMT-0600 (Horário Padrão Central)

Não deveria estar criando uma nova data em utc (sem fuso horário)? Além disso, o primeiro console.log mostra o objeto momento com um fuso horário cst e não o horário utc.

Thu Dec 13 2012 18:29:40 GMT-0600 é na verdade exatamente o mesmo tempo que 2012-12-14T00:29:40.276Z . Eles são apenas maneiras diferentes de exibir ao mesmo tempo. Se quiser, você pode ver isso fazendo o seguinte.

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

O JS Date nativo não tem um modo utc vs local, ele apenas tem acessores como getUTCHours e getHours .

Moment.js abstrai esses métodos getUTC* vs get* com a ideia de modo utc e modo local. Se o momento estiver no modo utc, ele usa os métodos getUTC* . Se estiver no modo local, ele usa os métodos get* .

Obrigado, pelo esclarecimento.

Eu estava esperando e pensei que sinze o padrão iso afirma que Z significa nenhum fuso horário que o padrão seria utc. Portanto, se você fizesse moment.utc ('2012-12-14T00: 29: 40.276Z') ou moment ('2012-12-14T00: 29: 40.276Z'), ambos seriam tratados como utc e o sinalizador utc seria definido como verdadeiro.

PS, desculpe por incomodar tanto:. Estou criando uma nova discussão para uma pergunta diferente: s

Sem problemas.

A razão de não definirmos o sinalizador isUTC com moment() e moment.utc() é porque, embora você possa estar analisando uma string UTC + 0, pode querer exibir o momento no fuso horário dos usuários.

Este é um caso de uso bastante comum, pois é uma boa prática armazenar horários como strings ISO8601 UTC + 0 no back-end e exibi-los no front-end no fuso horário do usuário.

Obrigado, espero que outra pessoa também considere esta discussão útil.

Quando executo o console.log (moment.utc ()), ele informa "Sex Jan 18 2013 16:25:32 GMT-0800 (UTC)" No entanto, esse é o horário local do Pacífico, NÃO o horário UTC atual. Uma vez que diz explicitamente (UTC) quando o registro, presumo que ele pensa que "16:25:32" está no horário UTC, mas é de fato o horário do Pacífico local ...

Além disso, estou assumindo que moment.utc (). ValueOf () está retornando o número de milissegundos em UTC desde a época, o que parece estar incorreto. Você já viu algum desse comportamento?

console.log (momento ())
H {_d: Sex. 18 de janeiro de 2013 16:51:20 GMT-0800 (UTC), _isUTC: falso, _a: nulo, _lang: falso}
console.log (moment.utc ())
H {_d: Sex. 18 de janeiro de 2013 16:51:20 GMT-0800 (UTC), _isUTC: verdadeiro, _a: nulo, _lang: falso}

Parece que tudo o que está fazendo é inverter o sinalizador _isUTC. : P Parece estar retornando a hora local, independentemente de eu especificar ou não .utc ().

Sim, .utc e .local basta virar a bandeira .isUTC que é usada em todos os getters e setters.

Como o Date.toString nativo é exibido no horário local, você está vendo a mesma representação em ambas as instâncias.

No entanto, .format usa o sinalizador .isUTC , portanto, formatar um momento com o sinalizador isUTC definido como verdadeiro será formatado conforme o esperado.

Veja as diferenças abaixo em relação a Date.prototype.toString , Date.prototype.toUTCString e 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"

Mesmo problema aqui:
moment (). valueOf () e moment (). utc (). valueOf ()
retorna o mesmo valor! : desapontado:

Portanto, para obter os milissegundos utc, preciso:

moment().valueOf() - (moment().utcOffset() * 60 * 1000)

@rubenspgcavalcante - Não tenho certeza do que você está perguntando. Esses dois estão _supostos_ a retornar o mesmo valor, ambos em milissegundos desde a época unix.

O trecho que você escreveu realmente retorna um momento diferente no tempo.

Estou tendo um problema semelhante onde o sinalizador UTC é definido como verdadeiro, mas quando eu cal format (); Ele retorna a hora local. Aqui está uma captura de tela.

screen shot 2016-07-10 at 8 50 15 am

A linha após o objeto é um console.log do var após eu chamar format (); nele.

Estou fazendo algo errado?

@ james-hoegerl, parece que o objeto de data interno é 5 de julho de 2016 às 19:00 central. Adicione cinco horas a isso para chegar ao UTC, e é 6 de julho, que é o que parece ser um registro. Resumindo, não vejo nada de errado.
Parece que você está usando fullcalendar. Ele faz alguma extensão / patching de momento que pode causar um comportamento incomum.

Ok, talvez eu esteja apenas confuso sobre uct. Pensei em obter "2016-05-07 07:00:00" e então armazenar isso no banco de dados e obter a hora local para cada computador do usuário final por meio de moment.

Portanto, em primeiro lugar, assumirei que você quis dizer 6016-07-05 (5 de julho, não 7 de maio). Seu horário local é 5 de julho às 19:00. Ajustado para a luz do dia central dos EUA, adicionamos cinco horas. Isso resulta em 6 de julho à meia-noite.

Se você pretende chegar em 5 de julho, acho que o que você realmente quer é a hora local, não UTC. Você poderia chamar .local () no momento para voltar para a hora local.

Você pode achar isso útil: https://maggiepint.com/2016/05/14/moment-js-shows-the-wrong-date/

Muito obrigado pela sua ajuda @maggiepint. Sim, meu comentário anterior quis dizer 7-5. Desculpe por ter escrito esse comentário às pressas no meu telefone na piscina neste fim de semana. Eu vejo onde meu pensamento está para trás agora. fullcalendar funciona em todos os objetos de momento com zoneamento de tempo ambíguo, então acho que estava apenas tendo algum mal-entendido e preciso fazer alguns detalhes sobre isso. Obrigado novamente pelo seu tempo @maggiepint

Olá, Para converter UTC em hora do usuário, precisamos fornecer o formato.
por exemplo: let utcTime = moment ({hora: 10, minuto: 20) .format ('AAAA-MM-DD HH: mm: ss');
deixe stillUtc = moment.utc (utcTime) .toDate ();
deixe localTime = moment (stillUtc) .local ();
Agora posso obter o localTIme. Mas se eu remover o formato, ainda posso formatar UTC. aqui 10:20 é o fuso horário UTC, que está vindo do backend. Quero mostrar isso ao usuário no fuso horário do usuário.

Por favor me ajude.

Mesmo problema aqui:
moment (). valueOf () e moment (). utc (). valueOf ()
retorna o mesmo valor! 😞
Portanto, para obter os milissegundos utc, preciso:
moment (). valueOf () - (moment (). utcOffset () * 60 * 1000)

@rubenspgcavalcante - Não tenho certeza do que você está perguntando. Esses dois devem retornar o mesmo valor, ambos em milissegundos desde a época do unix.

@ mj1856 Não entendo como moment (). valueOf () e moment (). utc (). valueOf () devem retornar o mesmo valor ??

Devo acrescentar à expressão de confusão em torno da funcionalidade UTC. A expectativa mais intuitiva de moment.utc () seria que ele retornaria um objeto Moment representando a data / hora do now no horário UTC. Mas, de acordo com esta discussão, não é o caso e apenas define a bandeira. Ainda não está claro o que essa bandeira faz. Nada disso é mencionado na documentação, o que a torna terrivelmente inadequada. Por favor, acrescente esclarecimentos sobre este tópico com exemplos para o seu backlog. Obrigado.

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

tanepiper picture tanepiper  ·  3Comentários

vbullinger picture vbullinger  ·  3Comentários

slavafomin picture slavafomin  ·  3Comentários

chitgoks picture chitgoks  ·  3Comentários

nikocraft picture nikocraft  ·  3Comentários