Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of jens@couchbase.com designates
 206.225.164.29 as permitted sender)
From: Jens Alfke <jens@couchbase.com>
To: "user@couchdb.apache.org" <user@couchdb.apache.org>
Date: Thu, 7 Mar 2013 17:30:28 -0800
Subject: Re: map timezones
Thread-Topic: map timezones
Thread-Index: Ac4bnIP4Sym8WnU4QfWICCuggloUHQ==
Message-ID: <BB97B5AE-C3B6-413E-ACA4-977498F705A0@couchbase.com>
References: 
 <CAHGcXejH1N2=R98qBQ2nXz4kq5+q0RNFghcBv1odm_GNoWskpQ@mail.gmail.com>
In-Reply-To: 
 <CAHGcXejH1N2=R98qBQ2nXz4kq5+q0RNFghcBv1odm_GNoWskpQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On Mar 6, 2013, at 9:24 PM, Will Heger <will.heger@gmail.com> wrote:

> In that way, as a developer I can store times within my document using
> either UTC or epoch times.  These times could be current or historical, i=
t
> doesn't matter.  What matters is that they're unambiguous. And there exis=
ts
> a pure function F such that:
> F(doc.epoch_time, doc.location) =3D A time for that locale for that momen=
t
> in history

I imagine that=92s likely to be a fairly _slow_ function, though, which mak=
es it a bad choice to call inside map/reduce. People have already found the=
ir view performance being bottlenecked by simpler tasks like basic date par=
sing.

> Absent this, I think the best idea is to store the epoch time and force t=
he
> client to also stamp the relevant local UTC offset.  It offers the most
> flexibility in terms of reporting, deals with DST weirdness, and I have
> more resources to look-up UTC offsets from client code than in couch.

The standard date/time format already supports this, since it gives the tim=
e in UTC and appends the numeric offset for local time. (E.g. =9323:53:30-0=
800=94.)

=97Jens=