On 22/05/2015 06:09, Adrian Klaver wrote:
> On 05/21/2015 09:04 PM, Alvaro Herrera wrote:
>> Adrian Klaver wrote:
>>
>>> SELECT
>>> extract (
>>> YEAR
>>> FROM
>>> school_day ) AS YEAR,
>>
>>> Reformatting courtesy of pgFormatter(http://sqlformat.darold.net/).
>>
>> FWIW
On Fri, May 22, 2015 at 09:46:10AM +0100, Tim Clarke wrote:
> On 22/05/15 09:40, Alban Hertroys wrote:
> > On 21 May 2015 at 23:42, Karsten Hilbert wrote:
> >
> >> You are right in the following aspect:
> >>
> >> - client sends in "NOW at HERE"
> >> - server knows HERE = UTC+2
> > And then the te
On 22/05/15 09:40, Alban Hertroys wrote:
> On 21 May 2015 at 23:42, Karsten Hilbert wrote:
>
>> You are right in the following aspect:
>>
>> - client sends in "NOW at HERE"
>> - server knows HERE = UTC+2
> And then the tectonic plate you're on shifts and you're suddenly in UTC+1 or
> +3
>
> Thank
On 21 May 2015 at 23:42, Karsten Hilbert wrote:
> You are right in the following aspect:
>
> - client sends in "NOW at HERE"
> - server knows HERE = UTC+2
And then the tectonic plate you're on shifts and you're suddenly in UTC+1 or +3
Thankfully, those things don't shift as fast as they sometim
On 05/21/2015 09:04 PM, Alvaro Herrera wrote:
Adrian Klaver wrote:
SELECT
extract (
YEAR
FROM
school_day ) AS YEAR,
Reformatting courtesy of pgFormatter(http://sqlformat.darold.net/).
FWIW I think this indenting of FROM inside an extract() call is odd and
ugly -
Adrian Klaver wrote:
> SELECT
> extract (
> YEAR
> FROM
> school_day ) AS YEAR,
> Reformatting courtesy of pgFormatter(http://sqlformat.darold.net/).
FWIW I think this indenting of FROM inside an extract() call is odd and
ugly --- probably just an accident resulting from
On 05/21/2015 11:56 AM, Steve Crawford wrote:
On 05/21/2015 10:45 AM, Paul Jungwirth wrote:
You really shouldn't use WITHOUT TIME ZONE.
I'd like to know more about this. Can you say why?
Start by reading about the date and time data types with special
attention to section 8.5.3:
www.postgres
On 05/21/2015 11:02 AM, Daniel Torres wrote:
Sorry, forgot to told you what I'm trying, I have climate data and want
to obtain mean temperature and total precipitation and that sort of
things per month and year. Think date_trunc is a good solution, but any
other advice would be very welcome.
As
> It's probably worth noting that both the Ruby 'best practice' AND
> Postgres have a failure case when dealing with future dates precisely
> because they are storing the data as UTC with a time zone. This is
> one case where storing the data WITHOUT TIME ZONE would actually save
> your bacon.
>
On Thu, May 21, 2015 at 5:27 PM, Thomas Kellerer wrote:
> Postgres does not store the time zone. When storing a timestamp with time
> zone, it
> is normalized to UTC based on the timezone of the client. When you retrieve
> it,
> it is adjusted to the time zone of the client.
>
Sorry, I misspoke.
what you've said above is incorrect.
All "WITH TIME ZONE" does is tell PostgreSQL to apply timezone
conversions during various operations. The stored data is represented
as an epoch without any concept of the source data's timezone
representation.
Oh, very interesting! Thank you for pointing th
> Anyway, I agree that you have to store the time zone *somewhere*, and I
> suppose that's the reason Joshua remarked that you really shouldn't use
> WITHOUT TIME ZONE. And often a time has one perspective that is
> "canonical" or "preferred", e.g. the time zone of the user who created
> the ob
Brian Dunavant wrote on 21.05.2015 21:51:
It's probably worth noting that both the Ruby 'best practice' AND
Postgres have a failure case when dealing with future dates precisely
because they are storing the data as UTC with a time zone. This is
one case where storing the data WITHOUT TIME ZONE w
On Thu, May 21, 2015 at 2:10 PM, Paul Jungwirth wrote:
> Anyway, I agree that you have to store the time zone *somewhere*, and I
> suppose that's the reason Joshua remarked that you really shouldn't use
> WITHOUT TIME ZONE. And often a time has one perspective that is "canonical"
> or "preferred"
Hi Steve,
Thanks for such a thorough response! I agree that time is a lot trickier
and trappier than one might expect, so it's good to learn how others
grapple with it.
> Your original question had to do with month/year.
Just to clarify, that was Daniel's original question, but you're
reply
On May 21, 2015 11:56:52 AM Steve Crawford wrote:
> The article does also display a couple attitudes that I feel are especially
> rampant in the web-development community. The first is that web developers
> shouldn't become educated about the capabilities of a database but rather
> use the database
It's probably worth noting that both the Ruby 'best practice' AND
Postgres have a failure case when dealing with future dates precisely
because they are storing the data as UTC with a time zone. This is
one case where storing the data WITHOUT TIME ZONE would actually save
your bacon.
>From the po
On 05/21/2015 10:45 AM, Paul Jungwirth wrote:
You really shouldn't use WITHOUT TIME ZONE.
I'd like to know more about this. Can you say why?
Start by reading about the date and time data types with special
attention to section 8.5.3:
www.postgresql.org/docs/current/static/datatype-datetime.
Sorry, forgot to told you what I'm trying, I have climate data and want to
obtain mean temperature and total precipitation and that sort of things per
month and year. Think date_trunc is a good solution, but any other advice
would be very welcome.
(I need to read more about time zones, I'm new at
You really shouldn't use WITHOUT TIME ZONE.
I'd like to know more about this. Can you say why? Are there any
articles you'd recommend? I'm fond of normalizing all times to UTC and
only presenting them in a time zone when I know the current
"perspective". I've written about that approach in a
On 05/21/2015 10:01 AM, Daniel Torres wrote:
I everybody, I'm new in the Postgresql world, and have an easy
question: Is it possible to have date type data that only contain
month and year?, how can I obtain that from a timestamp (without time
zone) column?...
Others have offered good tips bu
On 05/21/2015 10:01 AM, Daniel Torres wrote:
I everybody, I'm new in the Postgresql world, and have an easy question:
Is it possible to have date type data that only contain month and year?,
how can I obtain that from a timestamp (without time zone) column?
I've made this, but I think the result
On Thursday, May 21, 2015, Daniel Torres wrote:
> I everybody, I'm new in the Postgresql world, and have an easy question:
> Is it possible to have date type data that only contain month and year?,
> how can I obtain that from a timestamp (without time zone) column?
>
> I've made this, but I thin
Is it possible to have date type data that only contain month and year?,
how can I obtain that from a timestamp (without time zone) column?
I think you want date_trunc, which will cut everything down to the first
of the month, e.g 2015-01-01, 2015-02-01, etc. The results will still be
dates, s
On Thu, May 21, 2015 at 12:01 PM, Daniel Torres wrote:
> I everybody, I'm new in the Postgresql world, and have an easy question:
> Is it possible to have date type data that only contain month and year?,
> how can I obtain that from a timestamp (without time zone) column?
>
> I've made this, but
25 matches
Mail list logo
