Re: Timezones (in 8.5?)
От | Kevin Grittner |
---|---|
Тема | Re: Timezones (in 8.5?) |
Дата | |
Msg-id | 4B02CE63020000250002C971@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Timezones (in 8.5?) (hernan gonzalez <hgonzalez@gmail.com>) |
Ответы |
Re: Timezones (in 8.5?)
|
Список | pgsql-hackers |
hernan gonzalez <hgonzalez@gmail.com> wrote: > I believe that this distinction between two realms: one related to > (say) "physical time" and the other to (say) "civil date-time", is > the key to put some order... conceptually, at least (I'm not > speaking about feasibility for now). This is the approach of some > Date-Time APIs, for example the "Joda" Java library > http://joda-time.sourceforge.net/ (headed to replace soon > https://jsr-310.dev.java.net/ the original ugly JDK Date-Calendar > API) and I believe it's the right way. Congratulations on the most sane and thoughtful discussion of this I've seen! In our shop we had so many problems with the "physical time" based implementation of dates, times, and timestamps in Java that we wrote our own library to cover our needs. I hadn't heard about Joda; we should probably look at it to see if we can migrate from our home-grown solution. One thing you didn't address is the "end-of-month" issues -- how do you handle an order that someone pay a set amount on a given date and monthly thereafter, when the date might be past the 28th? I'm curious to hear your opinion on that topic. I have seen in this real-world financial applications several times. They have usually wanted to go to the last day of the month when there aren't enough days in a given month, but then go back out to the original day-of-month whenever possible; but sometimes the payment "one month" after the 31st of January has to be 30 days past the 1st of the next month. The SQL standard solution to this is much ridiculed here, even though I suspect many have seen monthly bills or statements at some point in their lives.... ;-) -Kevin
В списке pgsql-hackers по дате отправления: