Полная текстовая строка date для Instant [duplicate]

Question

Полная текстовая строка date для Instant [duplicate]

Вы не можете записать такое ограничение в объявлении таблицы.

Существуют некоторые способы обхода:

Создайте триггер, который будет проверять количество фотографий для каждого пользователя [ ! d4]
Создайте столбец photo_order , который сохранит порядок фотографий, сделайте (user_id, photo_order) UNIQUE и добавьте CHECK (photo_order BETWEEN 1 И 10)

849

java date

задан bluish 5 December 2014 в 11:35

9 ответов

На это есть только один правильный ответ, и большинство систем ошибаются. Число миллисекунд с эпохи, а также 64-битное целое число. Часовой пояс - это проблема с пользовательским интерфейсом и не имеет бизнеса на уровне приложения или уровне db. Почему ваш db заботится о том, что в часовом поясе что-то есть, когда вы знаете, что он будет хранить его в виде 64-битного целого числа, тогда выполните вычисления преобразования.

Разделите посторонние биты и просто обработайте даты как числа до пользовательский интерфейс. Вы можете использовать простые арифметические операторы для выполнения запросов и логики.

-3

ответ дан Chad Wilson 16 August 2018 в 11:00
поделиться

1

Комментарии были перемещены в чат . – Jon Clements♦ 7 June 2016 в 17:13

2

– aij 21 September 2016 в 18:51

3

Итак, как вы представляете микросекунды? RFC3339 отлично работает с любой точностью, у вас будет читатель, который анализирует часовой пояс и дает вам правильную отметку времени, и это дополнительная информация. Приложения для календаря обычно заботятся о часовых поясах. – gnasher729 4 November 2016 в 18:05

4

Часовой пояс не относится к пользовательскому интерфейсу, если вы не пропустите свой следующий рейс. Полеты отправляются по местному времени и следуют определенным правилам для изменений ДСТ. Потеря смещения означает потерю важной деловой информации – Panagiotis Kanavos 5 December 2016 в 13:00

5

Некоторые дополнительные контраргументы включают способность представлять времена до 1970 года (при условии, что определенная эпоха), и JSONs склонны быть читаемыми человеком. – Timo 13 December 2016 в 17:36

В Sharepoint 2013, получая данные в JSON, нет формата для преобразования даты только в формат даты, потому что в эту дату должен быть формат ISO

yourDate.substring(0,10)

Это может быть полезно для вас

1

ответ дан irundaia 16 August 2018 в 11:00
поделиться

Из RFC 7493 (Формат сообщений I-JSON) :

I-JSON означает либо Internet JSON, либо Interoperable JSON, в зависимости от того, кого вы спросите.

Протоколы часто содержат элементы данных, предназначенные для хранения временных меток или продолжительности времени. РЕКОМЕНДОВАНО, чтобы все такие элементы данных были выражены в виде строковых значений в формате ISO 8601, как указано в RFC 3339 , с дополнительными ограничениями, которые используются в верхнем регистре, а не в нижнем регистре, чтобы включить часовой пояс не по умолчанию, и что дополнительные секундные секунды включаются, даже если их значение равно «00». Также РЕКОМЕНДОВАНО, что все элементы данных, содержащие временные интервалы, соответствуют «длительности» производства в Приложении А RFC 3339 с теми же дополнительными ограничениями.

19

ответ дан John Flatness 16 August 2018 в 11:00
поделиться

1

Это также формат, созданный Date().toISOString() и Date().toJSON(), с ограничением, что Date не отслеживает значение часового пояса и, следовательно, всегда испускает отметки времени в часовом поясе UTC (Z). Значение можно проанализировать с помощью new Date("...") и Date.parseDate. – Søren Løvborg 21 September 2015 в 09:06

Я думаю, что это действительно зависит от варианта использования. Во многих случаях было бы более полезно использовать правильную объектную модель (вместо того, чтобы давать дату в строку), например:

{ "year": 2012, "month": 4, "day": 23, "hour": 18, "minute": 25, "second": 43, "timeZone": "America/New_York" }

По общему признанию, это более подробно, чем RFC 3339, но:

также читается человеком

, он реализует правильную объектную модель (как в ООП, насколько это разрешено JSON)

поддерживает часовые пояса ( не только смещение UTC в заданную дату и время)

он может поддерживать меньшие единицы, такие как миллисекунды, наносекунды, ... или просто дробные секунды

он не требует отдельного шаг синтаксического анализа (для синтаксического анализа строки даты и времени), парсер JSON сделает все для вас

легкое создание с любой фреймворком даты или реализацией на любом языке

расширенный для поддержки других календарных шкал (иврит, китайский, исламский ...) и эпох (AD, BC, ...)

это год 10000 безопасен ;-) (RFC 3339 нет)

поддерживает дневные даты и плавающие времена (Javascript's Date.toJSON() не делает)

Я не думаю что правильная сортировка (как отмечено funroll для RFC 3339) - это функция, которая действительно необходима при сериализации даты для JSON. Также это верно только для дат-времени, имеющих одинаковое смещение часового пояса.

-12

ответ дан Marten 16 August 2018 в 11:00
поделиться

1

Я сомневаюсь, что кто-то будет использовать json в год 10000 или даже к тому времени 10000 год будет по-прежнему 10000 годом. Но если обе эти вещи по-прежнему верны, формат можно просто расширить, чтобы содержать 3 цифры век. Поэтому я бы сказал, что люди могут безопасно придерживаться RFC 3339, по крайней мере, до 9900 года – memory of a dream 9 March 2016 в 13:15

2

@ downvoters: Согласно Почему важно голосование? , вы должны понизить, если post contains wrong information, is poorly researched, or fails to communicate information. Пожалуйста, объясните, по какой из этих причин вы отклонили этот ответ. – Marten 7 June 2016 в 20:11

3

@Marten Две вещи. 1. Вы никогда не обязаны объяснением для downvotes, хотя я понимаю, что это может быть полезно. 2. Я не ответил на ваш ответ, но я бы предположил, что людям не нравится ваш ответ, потому что они думают, что это неправильный способ сделать это. Это может квалифицировать его как «Неверная информация». потому что вопрос ищет лучший способ сделать что-то – Kevin Wells 29 June 2016 в 17:52

4

Я не спустил вас вниз, но я могу, конечно, понять, как «изобретать еще один плохо определенный формат». (в основном это то, что вы говорите) будет считаться неправильным или плохо исследованным. – aij 22 September 2016 в 13:45

5

@Phil, UTC не является часовым поясом (нет места на земле, которое использует «UTC» в качестве своего официального часового пояса), это стандарт времени . Также смещения часовых поясов весьма непредсказуемы. Нельзя сказать, если бы в 2025 году "12: 00 московское время" все еще "9: 00 UTC" как и сегодня, он был изменен пару раз за последние 30 лет . Если вы хотите выразить будущее по местному времени, вам нужны настоящие часовые пояса. – Marten 8 August 2017 в 07:45

JSON ничего не знает о датах. Что делает .NET нестандартным хаком / расширением.

Я бы использовал формат, который можно легко преобразовать в объект Date в JavaScript, то есть тот, который можно передать в new Date(...) . Самый простой и, вероятно, самый переносимый формат - это метка времени, содержащая миллисекунды с 1970 года.

106

ответ дан Peter Mortensen 16 August 2018 в 11:00
поделиться

1

Ugh, я бы ожидал ошибки ... Но по крайней мере firefox действительно строит его ... ну, это не часть стандарта JSON, поэтому я не буду подавать объект Date в сериализатор JSON - он может не работать во всех браузеры. По-видимому, для сериализаторов JSON принято использовать функцию toJSON(), если она существует на неизвестном объекте. По крайней мере, Firefox делает это для объектов Date и объектов Date таким способом. – ThiefMaster♦ 23 April 2012 в 19:40

2

stackoverflow.com/questions/10286385/… - посмотрим, знает ли кто, почему FF ведет себя так. – ThiefMaster♦ 23 April 2012 в 19:47

3

Если вы идете по этому маршруту, убедитесь, что вам не нужно иметь дело с датами раньше 1970 года! – Ben Dolman 9 May 2013 в 22:14

4

Это также предпочтительные представления в соответствии с ECMA : JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}" – Steven 21 October 2013 в 14:28

5

Как сказал @BenDolman, это «решение» не относится к датам до 1 января 1970 года (Эпоха). Кроме того, в первую очередь существует причина, по которой существует стандарт ISO8601. Здесь, на Земле, мы называем «часовые пояса». Где это в миллисекундах? JSON может не иметь стандарта для дат, но даты существуют вне JSON, а является стандартом для этого. Ответ funroll является правильным (см. также: xkcd.com/1179 ). – JoeLinux 14 November 2013 в 22:19

6

Я бы добавил еще одну важную причину в список: он не зависит от языка. Если у вас была дата 02-03-2014, вам понадобится дополнительная информация, чтобы узнать, относится ли она к 3 февраля или 2 марта. Это зависит от того, используется ли формат US-формат или другой формат. – Juanal 2 July 2014 в 08:41

7

upvote для упоминания и связывания xkcd: D @ajorquera Обычно для этого я использую momentjs. Я также видел проблемы с IE в этом отношении – fholzer 29 April 2015 в 16:12

8

Что касается второго момента, он не сортирует правильно после 10000 года. У нас есть почти 8000 лет, чтобы придумать новый формат, так что это, вероятно, не проблема. – Erfa 19 August 2015 в 14:29

9

Возможно, стоит также упомянуть, что (милли) секунд с 1970 года не предсказуемо для дат в будущем, потому что у нас есть прыжок секунд . Поэтому я бы не использовал, если для межпроцессного общения и хранения данных. Тем не менее, неплохо использовать внутренне в программе, так как оно может храниться в одном целое, что дает вам некоторые преимущества в производительности. – Brodie Garnet 3 November 2015 в 14:56

10

Фактически, @Erfa, так как - приходит перед цифрами в ASCII, он будет сортироваться только до 100 000. ;П – Ben Leggiero 2 May 2016 в 18:23

Для меня работал следующий код. Этот код будет печатать дату в формате DD-MM-YYYY.

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

else, вы также можете использовать:

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

0

ответ дан Phil3992 16 August 2018 в 11:00
поделиться

это работа для меня с 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" } }

-4

ответ дан Rosdi Kasim 16 August 2018 в 11:00
поделиться

Только для справки я видел этот формат:

Date.UTC(2017,2,22)

Он работает с JSONP, который поддерживается функцией $.getJSON(). Не уверен, что я бы зашел так далеко, чтобы рекомендовать этот подход ... просто бросая его туда как возможность, потому что люди делают это таким образом.

FWIW: Никогда не используйте секунды с эпохи в протоколе связи, ни миллисекунд с эпохи, потому что это чревато опасностью благодаря рандомизированной реализации секунд прыжка (вы понятия не имеете, правильно ли передают отправители и получатели как секундные скачки UTC).

Вид домашней ненависти, но многие считают, что UTC - это просто новое имя для GMT - неправильно! Если ваша система не реализует секунды прыжка, вы используете GMT (часто называемый UTC, несмотря на то, что он неверен). Если вы полностью реализуете прыжковые секунды, вы действительно используете UTC. Невозможно знать будущие секунды прыжка; они публикуются IERS по мере необходимости и требуют постоянных обновлений. Если вы используете систему, которая пытается реализовать прыжки секунд, но содержит и устаревшую ссылочную таблицу (более часто, чем вы думаете), то у вас нет ни GMT, ни UTC, у вас есть система с выигрышем, претендующая на UTC.

Эти счетчики даты совместимы только при выражении в разбитом формате (y, m, d и т. д.). Они НИКОГДА не совместимы в формате эпохи. Имейте это в виду.

5

ответ дан Tel 16 August 2018 в 11:00
поделиться

1

– Robert Mikes 25 December 2017 в 12:47

Другие вопросы по тегам:
java date

Похожие вопросы:

100
Скрытые функции Java - 23 May 2017 02:26

73
[Закрываются] скрытые функции Eclipse - 6 May 2012 17:23

51
Почему это считают плохой практикой для исключения фигурных скобок? [закрытый] - 19 August 2016 17:07

48
Проверьте, верно ли хотя бы два из трех логических значений - 25 January 2013 22:30

47
Какова самая частая проблема параллелизма, с которой Вы встретились в Java? [закрытый] - 5 August 2012 12:49

41
Как я могу объединить два массива в Java? - 22 December 2018 15:35

41
Что возможно в IntelliJ, что невозможно в Eclipse? - 6 January 2012 05:17

score 31 · Answer 1

Нет правильного формата; Спецификация JSON не указывает формат обмена датами, поэтому существует так много разных способов сделать это.

Лучший формат - это, возможно, дата, представленная в Формат ISO 8601 ( см. В Википедии ); это хорошо известный и широко используемый формат и может обрабатываться на разных языках, что делает его очень подходящим для взаимодействия. Если у вас есть контроль над сгенерированным json, например, вы предоставляете данные другим системам в формате json, выбирая 8601, поскольку формат обмена датами является хорошим выбором.

Если у вас нет контроля над сгенерированным Например, json, вы являетесь потребителем json из нескольких разных существующих систем, лучший способ справиться с этим - иметь функцию служебной обработки синтаксиса даты для обработки ожидаемых различных форматов.

31

ответ дан Basil Bourque 16 August 2018 в 11:00

1

@mlissner, но это мнение , на котором лучше всего. ISO-8601 является стандартом, но это не стандарт для JSON (хотя я бы склонен его использовать); например, Microsoft решила не использовать его ( msdn.microsoft.com/en-us/library/… ). Лучшая практика - придерживаться одного (разумного) соглашения, что бы это ни было. Как я сказал в ответе, лучший способ справиться с этим - определить функцию утилиты синтаксического анализа даты, которая может обрабатывать ожидаемые форматы. Если вы интегрируетесь с системами, использующими разные форматы, функция должна обрабатывать каждый случай. – Russ Cam 30 April 2013 в 09:07

2

@RussCam, мы можем идти туда и обратно, но если кто-то просит наилучший способ кодирования дат в JSON, они спрашивают, как форматировать даты, когда они делают JSON (и ответ, как правило, ISO-8601). Вы отвечаете на противоположный вопрос: как потреблять даты JSON, как только они уже сделаны (хотя ваш совет звучит). – mlissner 30 April 2013 в 21:32

3

В спецификации схемы JSON фактически указано, что даты, которые проверяются схемой, должны быть в формате 8601. – gnasher729 16 January 2015 в 17:20

4

@ gnasher729 у вас есть ссылка? – Russ Cam 16 January 2015 в 22:56

5

@vallismortis - это проект спецификации для определения схемы для данной json-структуры, обмен которой происходит между сторонами, а не формат дат в спецификации json. Я собираюсь пересмотреть свой ответ, основываясь на комментариях, он не появляется, я ясно дал понять – Russ Cam 27 June 2015 в 00:32

score -3 · Answer 2

На это есть только один правильный ответ, и большинство систем ошибаются. Число миллисекунд с эпохи, а также 64-битное целое число. Часовой пояс - это проблема с пользовательским интерфейсом и не имеет бизнеса на уровне приложения или уровне db. Почему ваш db заботится о том, что в часовом поясе что-то есть, когда вы знаете, что он будет хранить его в виде 64-битного целого числа, тогда выполните вычисления преобразования.

Разделите посторонние биты и просто обработайте даты как числа до пользовательский интерфейс. Вы можете использовать простые арифметические операторы для выполнения запросов и логики.

-3

ответ дан Chad Wilson 16 August 2018 в 11:00

1

Комментарии были перемещены в чат . – Jon Clements♦ 7 June 2016 в 17:13
2

– aij 21 September 2016 в 18:51
3

Итак, как вы представляете микросекунды? RFC3339 отлично работает с любой точностью, у вас будет читатель, который анализирует часовой пояс и дает вам правильную отметку времени, и это дополнительная информация. Приложения для календаря обычно заботятся о часовых поясах. – gnasher729 4 November 2016 в 18:05
4

Часовой пояс не относится к пользовательскому интерфейсу, если вы не пропустите свой следующий рейс. Полеты отправляются по местному времени и следуют определенным правилам для изменений ДСТ. Потеря смещения означает потерю важной деловой информации – Panagiotis Kanavos 5 December 2016 в 13:00
5

Некоторые дополнительные контраргументы включают способность представлять времена до 1970 года (при условии, что определенная эпоха), и JSONs склонны быть читаемыми человеком. – Timo 13 December 2016 в 17:36

score 1 · Answer 3

В Sharepoint 2013, получая данные в JSON, нет формата для преобразования даты только в формат даты, потому что в эту дату должен быть формат ISO

yourDate.substring(0,10)

Это может быть полезно для вас

score 19 · Answer 4

Из RFC 7493 (Формат сообщений I-JSON) :

I-JSON означает либо Internet JSON, либо Interoperable JSON, в зависимости от того, кого вы спросите.

Протоколы часто содержат элементы данных, предназначенные для хранения временных меток или продолжительности времени. РЕКОМЕНДОВАНО, чтобы все такие элементы данных были выражены в виде строковых значений в формате ISO 8601, как указано в RFC 3339 , с дополнительными ограничениями, которые используются в верхнем регистре, а не в нижнем регистре, чтобы включить часовой пояс не по умолчанию, и что дополнительные секундные секунды включаются, даже если их значение равно «00». Также РЕКОМЕНДОВАНО, что все элементы данных, содержащие временные интервалы, соответствуют «длительности» производства в Приложении А RFC 3339 с теми же дополнительными ограничениями.

Это также формат, созданный Date().toISOString() и Date().toJSON(), с ограничением, что Date не отслеживает значение часового пояса и, следовательно, всегда испускает отметки времени в часовом поясе UTC (Z). Значение можно проанализировать с помощью new Date("...") и Date.parseDate. — Søren Løvborg, 21 September 2015 в 09:06

score -12 · Answer 5

Я думаю, что это действительно зависит от варианта использования. Во многих случаях было бы более полезно использовать правильную объектную модель (вместо того, чтобы давать дату в строку), например:

{
     "year": 2012,
     "month": 4,
     "day": 23,
     "hour": 18,
     "minute": 25,
     "second": 43,
     "timeZone": "America/New_York"
}

По общему признанию, это более подробно, чем RFC 3339, но:

также читается человеком
, он реализует правильную объектную модель (как в ООП, насколько это разрешено JSON)
поддерживает часовые пояса ( не только смещение UTC в заданную дату и время)
он может поддерживать меньшие единицы, такие как миллисекунды, наносекунды, ... или просто дробные секунды
он не требует отдельного шаг синтаксического анализа (для синтаксического анализа строки даты и времени), парсер JSON сделает все для вас
легкое создание с любой фреймворком даты или реализацией на любом языке
расширенный для поддержки других календарных шкал (иврит, китайский, исламский ...) и эпох (AD, BC, ...)
это год 10000 безопасен ;-) (RFC 3339 нет)
поддерживает дневные даты и плавающие времена (Javascript's Date.toJSON() не делает)

Я не думаю что правильная сортировка (как отмечено funroll для RFC 3339) - это функция, которая действительно необходима при сериализации даты для JSON. Также это верно только для дат-времени, имеющих одинаковое смещение часового пояса.

-12

ответ дан Marten 16 August 2018 в 11:00

1

Я сомневаюсь, что кто-то будет использовать json в год 10000 или даже к тому времени 10000 год будет по-прежнему 10000 годом. Но если обе эти вещи по-прежнему верны, формат можно просто расширить, чтобы содержать 3 цифры век. Поэтому я бы сказал, что люди могут безопасно придерживаться RFC 3339, по крайней мере, до 9900 года – memory of a dream 9 March 2016 в 13:15
2

@ downvoters: Согласно Почему важно голосование? , вы должны понизить, если post contains wrong information, is poorly researched, or fails to communicate information. Пожалуйста, объясните, по какой из этих причин вы отклонили этот ответ. – Marten 7 June 2016 в 20:11
3

@Marten Две вещи. 1. Вы никогда не обязаны объяснением для downvotes, хотя я понимаю, что это может быть полезно. 2. Я не ответил на ваш ответ, но я бы предположил, что людям не нравится ваш ответ, потому что они думают, что это неправильный способ сделать это. Это может квалифицировать его как «Неверная информация». потому что вопрос ищет лучший способ сделать что-то – Kevin Wells 29 June 2016 в 17:52
4

Я не спустил вас вниз, но я могу, конечно, понять, как «изобретать еще один плохо определенный формат». (в основном это то, что вы говорите) будет считаться неправильным или плохо исследованным. – aij 22 September 2016 в 13:45
5

@Phil, UTC не является часовым поясом (нет места на земле, которое использует «UTC» в качестве своего официального часового пояса), это стандарт времени . Также смещения часовых поясов весьма непредсказуемы. Нельзя сказать, если бы в 2025 году "12: 00 московское время" все еще "9: 00 UTC" как и сегодня, он был изменен пару раз за последние 30 лет . Если вы хотите выразить будущее по местному времени, вам нужны настоящие часовые пояса. – Marten 8 August 2017 в 07:45

score 106 · Answer 6

JSON ничего не знает о датах. Что делает .NET нестандартным хаком / расширением.

Я бы использовал формат, который можно легко преобразовать в объект Date в JavaScript, то есть тот, который можно передать в new Date(...) . Самый простой и, вероятно, самый переносимый формат - это метка времени, содержащая миллисекунды с 1970 года.

106

ответ дан Peter Mortensen 16 August 2018 в 11:00

1

Ugh, я бы ожидал ошибки ... Но по крайней мере firefox действительно строит его ... ну, это не часть стандарта JSON, поэтому я не буду подавать объект Date в сериализатор JSON - он может не работать во всех браузеры. По-видимому, для сериализаторов JSON принято использовать функцию toJSON(), если она существует на неизвестном объекте. По крайней мере, Firefox делает это для объектов Date и объектов Date таким способом. – ThiefMaster♦ 23 April 2012 в 19:40
2

stackoverflow.com/questions/10286385/… - посмотрим, знает ли кто, почему FF ведет себя так. – ThiefMaster♦ 23 April 2012 в 19:47
3

Если вы идете по этому маршруту, убедитесь, что вам не нужно иметь дело с датами раньше 1970 года! – Ben Dolman 9 May 2013 в 22:14
4

Это также предпочтительные представления в соответствии с ECMA : JSON.stringify({'now': new Date()}) "{"now":"2013-10-21T13:28:06.419Z"}" – Steven 21 October 2013 в 14:28
5

Как сказал @BenDolman, это «решение» не относится к датам до 1 января 1970 года (Эпоха). Кроме того, в первую очередь существует причина, по которой существует стандарт ISO8601. Здесь, на Земле, мы называем «часовые пояса». Где это в миллисекундах? JSON может не иметь стандарта для дат, но даты существуют вне JSON, а является стандартом для этого. Ответ funroll является правильным (см. также: xkcd.com/1179 ). – JoeLinux 14 November 2013 в 22:19

6

Я бы добавил еще одну важную причину в список: он не зависит от языка. Если у вас была дата 02-03-2014, вам понадобится дополнительная информация, чтобы узнать, относится ли она к 3 февраля или 2 марта. Это зависит от того, используется ли формат US-формат или другой формат. – Juanal 2 July 2014 в 08:41

7

upvote для упоминания и связывания xkcd: D @ajorquera Обычно для этого я использую momentjs. Я также видел проблемы с IE в этом отношении – fholzer 29 April 2015 в 16:12

8

Что касается второго момента, он не сортирует правильно после 10000 года. У нас есть почти 8000 лет, чтобы придумать новый формат, так что это, вероятно, не проблема. – Erfa 19 August 2015 в 14:29

9

Возможно, стоит также упомянуть, что (милли) секунд с 1970 года не предсказуемо для дат в будущем, потому что у нас есть прыжок секунд . Поэтому я бы не использовал, если для межпроцессного общения и хранения данных. Тем не менее, неплохо использовать внутренне в программе, так как оно может храниться в одном целое, что дает вам некоторые преимущества в производительности. – Brodie Garnet 3 November 2015 в 14:56

10

Фактически, @Erfa, так как - приходит перед цифрами в ASCII, он будет сортироваться только до 100 000. ;П – Ben Leggiero 2 May 2016 в 18:23

score 0 · Answer 7

Для меня работал следующий код. Этот код будет печатать дату в формате DD-MM-YYYY.

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

else, вы также можете использовать:

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

score -4 · Answer 8

это работа для меня с 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"
            }
}

score 5 · Answer 9

Только для справки я видел этот формат:

Date.UTC(2017,2,22)

Он работает с JSONP, который поддерживается функцией $.getJSON(). Не уверен, что я бы зашел так далеко, чтобы рекомендовать этот подход ... просто бросая его туда как возможность, потому что люди делают это таким образом.

FWIW: Никогда не используйте секунды с эпохи в протоколе связи, ни миллисекунд с эпохи, потому что это чревато опасностью благодаря рандомизированной реализации секунд прыжка (вы понятия не имеете, правильно ли передают отправители и получатели как секундные скачки UTC).

Вид домашней ненависти, но многие считают, что UTC - это просто новое имя для GMT - неправильно! Если ваша система не реализует секунды прыжка, вы используете GMT (часто называемый UTC, несмотря на то, что он неверен). Если вы полностью реализуете прыжковые секунды, вы действительно используете UTC. Невозможно знать будущие секунды прыжка; они публикуются IERS по мере необходимости и требуют постоянных обновлений. Если вы используете систему, которая пытается реализовать прыжки секунд, но содержит и устаревшую ссылочную таблицу (более часто, чем вы думаете), то у вас нет ни GMT, ни UTC, у вас есть система с выигрышем, претендующая на UTC.

Эти счетчики даты совместимы только при выражении в разбитом формате (y, m, d и т. д.). Они НИКОГДА не совместимы в формате эпохи. Имейте это в виду.