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.Hilbert@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 fast as they sometimes do in the movies.
> >
>
> But every spring and autumn we do have daylight savings. How does that
> work with time-zoney-woney timey-wimey calculations!
When we schedule a meeting beyond the next DST shift we
conventionally "know" that to mean "the meeting will be at
2pm local time THEN, whichever DST is in effect when THEN has
come". After all, the very idea of DST is to make 2pm a
sensible meeting start time regardless of floating daylight
(whether that actually works is another matter :-)
Now, with non-DST arbitrary shifts we don't know as much. It
*could* be that 2pm suddenly falls into the middle of darkness.
At which point meetings better be re-scheduled.
And that's the answer to that: it's an application problem,
meetings need to be _re-scheduled_ which is NOT PostgreSQL's
job.
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
