Re: [GENERAL] ISO week dates

Поиск
Список
Период
Сортировка
От Brendan Jurd
Тема Re: [GENERAL] ISO week dates
Дата
Msg-id 37ed240d0611091146h2d38896h95ea4d9a0f700b8c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [GENERAL] ISO week dates  ("Brendan Jurd" <direvus@gmail.com>)
Ответы Re: [GENERAL] ISO week dates
Re: [GENERAL] ISO week dates
Re: [GENERAL] ISO week dates
Re: [GENERAL] ISO week dates
Список pgsql-patches
The attached patch implements my proposal to extend support for the
ISO week date calendar.

I have added two new format fields for use with to_char, to_date and
to_timestamp:
    - ID for day-of-week
    - IDDD for day-of-year

This makes it possible to convert ISO week dates to and from text
fully represented in either week ('IYYY-IW-ID') or day-of-year
('IYYY-IDDD') format.

I have also added an 'isoyear' field for use with extract / date_part.

The patch includes documentation updates and some extra tests in the
regression suite for the new fields.

I have tried to implement these features with as little disruption to
the existing code as possible.  I built on the existing date2iso*
functions in src/backend/utils/adt/timestamp.c, and added a few
functions of my own, but I wonder if these functions would be more
appropriately located in datetime.c, alongside date2j and j2date?

I'd also like to raise the topic of how conversion from text to ISO
week dates should be handled, where the user has specified a bogus
mixture of fields.  Existing code basically ignores these issues; for
example, if a user were to call to_date('1998-01-01 2454050',
'YYYY-MM-DD J') the function returns 2006-01-01, a result of setting
the year field from YYYY, then overwriting year, month and day with
the values from the Julian date in J, then setting the month and day
normally from MM and DD.

2006-01-01 is not a valid representation of either of the values the
user specified.  Now you might say "ask a silly question, get a silly
answer"; the user shouldn't send nonsense arguments to to_date and
expect a sensible result.  But perhaps the right way to respond to a
broken timestamp definition is to throw an error, rather than behave
as though everything has gone to plan, and return something which is
not correct.

The same situation can arise if the user mixes ISO and Gregorian data;
how should Postgres deal with something like to_date('2006-250',
'IYYY-DDD')?  The current behaviour in my patch is actually to assume
that the user meant to say 'IYYY-IDDD', since "the 250th Gregorian day
of the ISO year 2006" is total gibberish.  But perhaps it should be
throwing an error message.

That's all for now, thanks for your time.
BJ

Вложения

В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Patch for SPI subtransaction memory leakage
Следующее
От: "Heikki Linnakangas"
Дата:
Сообщение: Grouped index items (for discussion for 8.3)