Блог

Главная - Вопросы по программированию - Поле Postgresql json содержит даты как в ГГГГ-ММ-ДД, так и в формате 13-значной метки времени unix

Поле Postgresql json содержит даты как в ГГГГ-ММ-ДД, так и в формате 13-значной метки времени unix

#json #regex #postgresql #date

Вопрос:

Я анализирую массив json, и одно поле, которое я извлекаю, — это closedate. Однако closedate имеет два разных формата дат: один-ГГГГ-ММ-ДД, а другой-13-значная метка времени. Я пытаюсь получить согласованное форматирование дат, а также сделать так, чтобы оно было целым числом по сравнению со строкой. Прямо сейчас запрос, возвращающий дату закрытия, выглядит так:

json_array_elements(ld.data->'Table1'->'Details')->>'closeDate' as closedate

и он возвращает дату закрытия в виде строки:

ID дата закрытия
1 2021-09-29
2 1606824000000

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

Редактировать: У меня есть

 case when x.closedate::text ~* '^[0-9]{13}

инструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:

ОШИБКА: значение поля дата/время выходит за пределы диапазона: "2020-10-23"

при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.

Комментарии:

1. Что вы пытались сделать до сих пор?

2. пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.

3. Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь. Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.

4. @WaisKamal У меня есть case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate' , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"

5. Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function. Выражение to_date(x.closedate,'MMDDYYYY') требует, чтобы данные были в указанном формате, но данные не в этом формате. Попробуй to_date(x.closedate,'yyyy-mm-dd') .

Ответ №1:

Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:

 create table regex_test (id int, fld_1 varchar);
insert into  regex_test values (1, '1606824000000'), (2, '2021-09-29');

 select * from regex_test ;
 id |     fld_1     
---- ---------------
  1 | 1606824000000
  2 | 2021-09-29

select 
    id, 
    case when fld_1 ~* '^[0-9]*

Ответ №2:

Я надеюсь, что этот запрос поможет вам

 with data as (
  select
    json_array_elements(data->'Table1'->'Details')->>'closeDate' as closedate 
  from your_table
)
select 
  case when closedate::text ~ '^[0-9]

Комментарии:

1. У меня есть запрос case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate, , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"

Ответ №3:

Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).

 select id, 
     , case when closedate ~* '^[0-9]{13}

Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.

Комментарии:

1. проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0. Это заявление о случае работает для близких дат в 13 - значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД

2. Не говорите просто, что у вас возникли проблемы, единственным ответом будет "Хорошо, так". Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще. Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет. Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста - без изображений .

3. обновил вопрос

then
to_timestamp(x.closedate::bigint/1000)
when x.closedate = '0' then null
when x.closedate = '' then null
else
to_date(x.closedate,'MMDDYYYY') end as transactionclosedate
инструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:

ОШИБКА: значение поля дата/время выходит за пределы диапазона: "2020-10-23"

при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.

Комментарии:

1. Что вы пытались сделать до сих пор?

2. пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.

3. Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь. Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.

4. @WaisKamal У меня есть case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate' , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"

5. Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function. Выражение to_date(x.closedate,'MMDDYYYY') требует, чтобы данные были в указанном формате, но данные не в этом формате. Попробуй to_date(x.closedate,'yyyy-mm-dd') .

Ответ №1:

Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:





Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 - значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет "Хорошо, так".   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста -     без изображений    .  


3.  обновил вопрос  



 then

        to_timestamp(fld_1::bigint/1000)

    else

        fld_1::timestamp end as ts_fld

from

    regex_test;

 id |         ts_fld

---- ------------------------

  1 | 2020-12-01 04:00:00-08

  2 | 2021-09-29 00:00:00-07


  


Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 - значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет "Хорошо, так".   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста -     без изображений    .  


3.  обновил вопрос  



 then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = '0' then null

                 when x.closedate = '' then null

            else

                 to_date(x.closedate,'MMDDYYYY') end as transactionclosedate

  


инструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: "2020-10-23"


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:




1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  



Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: "1605657600000"  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 - значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет "Хорошо, так".   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста -     без изображений    .  


3.  обновил вопрос  


then

    to_timestamp(closedate::numeric / 1000)::date

  else

    closedate::date

  end

from data;

 


Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  



 then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = ‘0’ then null

                 when x.closedate = » then null

            else

                 to_date(x.closedate,’MMDDYYYY’) end as transactionclosedate


инструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: «2020-10-23»


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:




1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  



Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  


then

        to_timestamp(fld_1::bigint/1000)

    else

        fld_1::timestamp end as ts_fld

from

    regex_test;

 id |         ts_fld

—- ————————

  1 | 2020-12-01 04:00:00-08

  2 | 2021-09-29 00:00:00-07


Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  


then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = ‘0’ then null

                 when x.closedate = » then null

            else

                 to_date(x.closedate,’MMDDYYYY’) end as transactionclosedateинструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: «2020-10-23»


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:


1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  


Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  



 then

                 to_timestamp(closedate::bigint/1000)

            when is_valid_iso_date(closedate) then

                 closedate::timestamp

            else

                 ‘-infinity’::timestamp      — or whatever to indicate Invalid Date.

  from  <your table> ;


Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.


Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  



 then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = ‘0’ then null

                 when x.closedate = » then null

            else

                 to_date(x.closedate,’MMDDYYYY’) end as transactionclosedate


инструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: «2020-10-23»


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:




1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  



Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  


then

        to_timestamp(fld_1::bigint/1000)

    else

        fld_1::timestamp end as ts_fld

from

    regex_test;

 id |         ts_fld

—- ————————

  1 | 2020-12-01 04:00:00-08

  2 | 2021-09-29 00:00:00-07


Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  


then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = ‘0’ then null

                 when x.closedate = » then null

            else

                 to_date(x.closedate,’MMDDYYYY’) end as transactionclosedateинструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: «2020-10-23»


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:


1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  


Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  



 then

    to_timestamp(closedate::numeric / 1000)::date

  else

    closedate::date

  end

from data;


Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  


then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = ‘0’ then null

                 when x.closedate = » then null

            else

                 to_date(x.closedate,’MMDDYYYY’) end as transactionclosedateинструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: «2020-10-23»


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:


1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  


Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  



 then

        to_timestamp(fld_1::bigint/1000)

    else

        fld_1::timestamp end as ts_fld

from

    regex_test;

 id |         ts_fld

—- ————————

  1 | 2020-12-01 04:00:00-08

  2 | 2021-09-29 00:00:00-07


Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:


1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:




1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  



 then

                 to_timestamp(x.closedate::bigint/1000)

                 when x.closedate = ‘0’ then null

                 when x.closedate = » then null

            else

                 to_date(x.closedate,’MMDDYYYY’) end as transactionclosedate


инструкция case работает для преобразования 13-значной метки времени в дату, но я получаю ошибку:


ОШИБКА: значение поля дата/время выходит за пределы диапазона: «2020-10-23»


при попытке преобразовать строки даты в правильном формате в даты в другой части инструкции case.


Комментарии:




1.  Что вы пытались сделать до сих пор?  


2.  пожалуйста, поделитесь образцом набора данных, который другие могут использовать для создания решения.  


3.  Я представляю ниже ответ на эту ситуацию, но долгосрочное решение заключается в том, чтобы не попасть в эту ситуацию в первую очередь.   Если это вообще возможно: а) Установите согласованный формат меток времени для всех записей б) Храните записи в таблице, отличной от JSON, чтобы вы могли применять тип.  


4.  @WaisKamal У меня есть   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate'    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  


5.  Ваш формат ввода не соответствует указанному формату ввода в функции t_date_function.   Выражение    to_date(x.closedate,'MMDDYYYY')    требует, чтобы данные были в указанном формате, но данные не в этом формате.   Попробуй   to_date(x.closedate,'yyyy-mm-dd')    .  



Ответ №1:




Пример одного из способов заставить это работать. Мои навыки регулярного выражения не сильны, поэтому у других может быть лучшее решение:






Ответ №2:




Я надеюсь, что этот запрос поможет вам






Комментарии:




1.  У меня есть запрос   case when x.closedate::text similar to '^[0-9] $' then to_timestamp(x.closedate::bigint/1000)::date else x.closedate::date end as transactionclosedate,    , но я получаю сообщение об ошибке: значение поля даты/времени выходит за пределы диапазона: «1605657600000»  



Ответ №3:




Любой из других ответов был бы в порядке, если бы существовали только указанные форматы. Однако для хранения этих форматов требуется текстовое поле, которое может содержать что угодно. Опасно предполагать, что если содержимое не состоит из 13 цифр, то это действительная дата ISO в формате. Я бы также подтвердил это (и проверил длину цифр).




Проблема в том, что  is_valid_iso_date  эта функция. Оказывается, однако, мне пришлось создать именно это пару лет назад, я сделаю результат доступным здесь.


ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: Хотя функция не дала никаких известных ошибочных результатов, она НЕ была полностью протестирована.




Комментарии:


1.  проверяется, что все остальные даты указаны в 13-значном формате, однако есть несколько пустых дат и одна дата, которая равна всего 0.   Это заявление о случае работает для близких дат в 13 — значном формате, но у меня возникли проблемы с возвратом остальных дат, где формат указан в ГГГГ-ММ-ДД  


2.  Не говорите просто, что у вас возникли проблемы, единственным ответом будет «Хорошо, так».   Расскажите, что вы получаете: ошибку, неправильные результаты, что-то еще.   Опубликуйте любое полное сообщение, лучше всего обновив вопрос, а затем небольшой комментарий на этот счет.   Aso публикует точные данные, с которыми у вас возникли проблемы, что вы получаете и чего ожидаете, все в виде текста —     без изображений    .  


3.  обновил вопрос  








	Метки: ,