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 karsten.hilb...@gmx.net wrote:
You are right in the following aspect:
- client sends in NOW at HERE
- server knows HERE = UTC+2
And then the
On 22/05/15 09:40, Alban Hertroys wrote:
On 21 May 2015 at 23:42, Karsten Hilbert karsten.hilb...@gmx.net 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
On 21 May 2015 at 23:42, Karsten Hilbert karsten.hilb...@gmx.net 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
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 I think this indenting of
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
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:
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
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 object.
On Thu, May 21, 2015 at 5:27 PM, Thomas Kellerer spam_ea...@gmx.net 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,
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
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
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
On Thu, May 21, 2015 at 2:10 PM, Paul Jungwirth p...@illuminatedcomputing.com
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
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:
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.
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 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
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 as
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
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
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 is a text, not a date
select extract (Year
On Thu, May 21, 2015 at 12:01 PM, Daniel Torres nobeea...@gmail.com 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
On Thursday, May 21, 2015, Daniel Torres nobeea...@gmail.com 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
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,
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
26 matches
Mail list logo
