O formato de data JSON" direita"

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

Não existe um formato adequado ; O Especificação JSON não especifica um formato para troca de datas que é por isso que existem tantas maneiras diferentes de fazê-lo.

O melhor formato é, sem dúvida, uma data representado em formato ISO 8601 (ver hotéis-pensão - ); é um bem conhecido e amplamente utilizado formato e pode ser tratada em muitas línguas diferentes, tornando-o muito bem adaptado para a interoperabilidade. Se tem controlo sobre a 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 a json gerada, por exemplo, você é o consumidor da 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.

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

Os Protocolos contêm frequentemente elementos de dados concebidos para conter horários ou durações temporais. Recomenda-se que todos estes dados os itens devem ser expressos como valores de cadeia de caracteres no formato ISO 8601, conforme especificado in RFC 3339 , with the additional restrictions that uppercase rather do que letras minúsculas usado, que o fuso-horário não em falta, e que os segundos de saída opcional devem ser incluídos mesmo quando o valor deles é"00". Recomenda-se também que todos os itens de dados que contenham durações temporais conformes com a produção" duração " em Apêndice A da RFC 3339, com as mesmas restrições adicionais.

Só para referência, já vi este formato usado:

Date.UTC(2017,2,22)

Funciona com JSONP que é suportado pela função $.getJSON(). Não tenho a certeza se iria tão longe a ponto de recomendar esta abordagem... É só uma possibilidade, porque as pessoas estão a fazê-lo desta maneira.

FWIW: nunca usar segundos desde a época de um protocolo de comunicação, nem milisegundos desde a época, porque estes são repletos de perigo graças à implementação aleatória do Salto segundos (você não tem idéia se o remetente e o destinatário ambos implementam corretamente os segundos de salto UTC).

Estes contadores de datas só são compatíveis quando expressos num formato discriminado (y, m, d, etc.). Eles nunca são compatíveis em um formato de época. Não te esqueças disso.

No Sharepoint 2013, obter dados em JSON não existe nenhum formato para converter a data em formato apenas Data, porque nessa data deve estar no formato ISO

yourDate.substring(0,10)

Isto pode ser útil para si

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

Caso contrário, Pode também utilizar:

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

É trabalho para mim com o servidor parse

{
    "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"
            }
}

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

• também é legível para o homem
• implementa um modelo de objeto próprio (como em OOP, na medida em que JSON o permite)
• suporta fusos horários (não apenas o deslocamento UTC na data e hora indicadas)
Pode suportar unidades menores como milisegundos, nanosegundos,.. ou simplesmente segundos fraccionais
• não é necessário um passo de análise separado( para analisar o texto de data-hora), o analisador de JSON fará tudo por si
• criação fácil com qualquer data-hora ou implementação em qualquer língua
• pode ser facilmente estendido para apoiar outras escalas de calendário (hebraico, Chinês, Islâmico ...) e eras (AD, BC,...)
É o ano 10000 seguro; -) (RFC 3339 isn'T)
• suporte todo o dia datas e horas flutuantes (o Javascript's Date.toJSON() Não)

Eu não acho que a ordenação correta (como observado pela funroll para a RFC 3339) é uma característica que é realmente necessária ao serializar uma data para JSON. Além disso, isso só é verdade para datas-tempos tendo o mesmo fuso horário offset.