javascript exemplo O formato de data JSON "certo"




string to json javascript (8)

De RFC 7493 (o formato de mensagem I-JSON) :

I-JSON significa Internet JSON ou Interoperable JSON, dependendo de quem você pergunta.

Os protocolos geralmente contêm itens de dados projetados para conter registros de data e hora ou tempos. É RECOMENDADO que todos esses itens de dados sejam expressos como valores de string no formato ISO 8601, conforme especificado na RFC 3339 , com restrições adicionais que maiúsculas em vez de minúsculas sejam usadas, que o fuso horário seja incluído como padrão e que os segundos finais sejam opcionais ser incluído mesmo quando o valor for "00". Também é RECOMENDADO que todos os itens de dados que contenham tempos de duração estejam em conformidade com a produção de "duração" no Apêndice A da RFC 3339, com as mesmas restrições adicionais.

Eu vi muitos padrões diferentes para o formato de data JSON:

"\"\\/Date(1335205592410)\\/\""         .NET JavaScriptSerializer
"\"\\/Date(1335205592410-0500)\\/\""    .NET DataContractJsonSerializer
"2012-04-23T18:25:43.511Z"              JavaScript built-in JSON object
"2012-04-21T18:25:43-05:00"             ISO 8601

Qual é o caminho certo? Ou melhor? Existe algum tipo de padrão sobre isso?


O código a seguir funcionou para mim. Este código imprimirá a data no formato DD-MM-AAAA .

DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);

mais, você também pode usar:

DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);

No Sharepoint 2013, obtendo dados em JSON não há formato para converter data em formato único de data, pois nessa data deve estar no formato ISO

yourDate.substring(0,10)

Isso pode ser útil para você


Eu acho que isso realmente depende do caso de uso. Em muitos casos, pode ser mais vantajoso usar um modelo de objeto adequado (em vez de renderizar a data em uma string), da seguinte forma:

{
"person" :
      {
 "name" : {
   "first": "Tom",
   "middle": "M",
  ...
}
 "dob" :  {
         "year": 2012,
         "month": 4,
         "day": 23,
         "hour": 18,
         "minute": 25,
         "second": 43,
         "timeZone": "America/New_York"
    }   
   }
}

É certo que isso é mais detalhado do que o RFC 3339, mas:

  • é legível também
  • ele implementa um modelo de objeto adequado (como em OOP, na medida em que o JSON permite)
  • suporta fusos horários (não apenas o deslocamento UTC na data e hora indicadas)
  • ele pode suportar unidades menores como milissegundos, nanossegundos, ... ou simplesmente segundos fracionários
  • ele não requer uma etapa de análise separada (para analisar a sequência de data e hora), o analisador JSON fará tudo para você
  • criação fácil com qualquer estrutura de data e hora ou implementação em qualquer idioma
  • pode ser facilmente estendido para suportar outras escalas de calendário (hebraico, chinês, islâmico ...) e eras (AD, BC, ...)
  • é ano 10000 seguro ;-) (RFC 3339 não é)
  • suporta datas e horários flutuantes durante todo o dia (o Date.toJSON() do Javascript não funciona)

Eu não acho que a classificação correta (como observado por funroll para RFC 3339) é um recurso que é realmente necessário ao serializar uma data para JSON. Isso também é válido apenas para data e hora com o mesmo deslocamento de fuso horário.


Não há formato certo ; A especificação JSON não especifica um formato para troca de datas, e é por isso que existem tantas maneiras diferentes de fazer isso.

O melhor formato é sem dúvida uma data representada no formato ISO 8601 ( veja Wikipedia ); é um formato bem conhecido e amplamente utilizado e pode ser tratado em várias linguagens diferentes, tornando-o muito adequado para a interoperabilidade. Se você tem controle sobre o json gerado, por exemplo, você fornece dados para outros sistemas no formato json, escolhendo 8601 como o formato de intercâmbio de data é uma boa escolha.

Se você não tem controle sobre o json gerado, por exemplo, você é o consumidor do json de vários sistemas existentes diferentes, a melhor maneira de lidar com isso é ter uma função de utilidade de análise de data para lidar com os diferentes formatos esperados.


é trabalho para mim com parse Server

{
    "ContractID": "203-17-DC0101-00003-10011",
    "Supplier":"Sample Co., Ltd",
    "Value":12345.80,
    "Curency":"USD",
    "StartDate": {
                "__type": "Date",
                "iso": "2017-08-22T06:11:00.000Z"
            }
}

Apenas para referência, vi este formato usado:

Date.UTC(2017,2,22)

Ele funciona com o JSONP, que é suportado pela função $.getJSON() . Não tenho certeza se eu iria tão longe a ponto de recomendar essa abordagem ... apenas lançar isso como uma possibilidade, porque as pessoas estão fazendo isso dessa maneira.

FWIW: Nunca use segundos desde a época em um protocolo de comunicação, nem milissegundos desde a época, porque eles são perigosos devido à implementação aleatória de segundos bissextos (você não tem idéia se o remetente e o receptor implementam corretamente os segundos bissextos UTC).

Tipo de animal de estimação ódio, mas muitas pessoas acreditam que o UTC é apenas o novo nome para GMT - errado! Se o seu sistema não implementar segundos bissextos, então você está usando o GMT (freqüentemente chamado de UTC, apesar de estar incorreto). Se você implementar completamente os segundos bissextos, você realmente está usando o UTC. Futuros segundos de salto não podem ser conhecidos; eles são publicados pelo IERS conforme necessário e exigem atualizações constantes. Se você estiver executando um sistema que tenta implementar segundos bissextos, mas contém uma tabela de referência desatualizada (mais comum do que você imagina), então você não tem nem GMT nem UTC, você tem um sistema instável fingindo ser UTC.

Estes contadores de data são compatíveis apenas quando expressos em um formato detalhado (y, m, d, etc). Eles NUNCA são compatíveis em um formato de época. Tenha isso em mente.


O JSON não sabe nada sobre datas. O que o .NET faz é um hack / extensão não padrão.

Eu usaria um formato que pode ser facilmente convertido em um objeto Date em JavaScript, ou seja, um que pode ser passado para a new Date(...) . O formato mais fácil e provavelmente mais portátil é o timestamp contendo milissegundos desde 1970.





json