On Wed, Feb 20, 2013 at 11:03 AM, Jonathan Adams <pointlessjon at me.com>wrote:

> Date.setLocalTimezone('America/Los_Angeles')
>
Date.getLocalTimezone()
>

Since ES Dates represent single points in time (you can't have a time
without a date or vice versa), there is no real reason to carry along a
timezone string with each Date instance. This is why I took the approach of
having a static method to simply construct a shifted Date into a particular
timezone. Once the Date object is in that timezone, there is no need to
preserve the timezone string because there can only be one valid offset for
it. You only need to preserve the timezone string when storing a recurring
date/time and ES does not have any native representation of such a thing.
Also, sometimes you do need to preserve the static offset because a
timezone string is not provided. Parsing a SMTP mail header timestamp is an
example of this.

Keeping simple offset storage for a Date makes sense. Then there can be
higher level functions which allow you to create Dates in a particular
timezone or convert between two timezones by manipulating the stored
offset. Yes, someone can resort to manual offset fudgery and create DST
bugs, but hiding offset away would prevent people who *do* know what
they're doing what they need.

-Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130220/a7b17f3e/attachment.html>

On Wed, Feb 20, 2013 at 11:03 AM, Jonathan Adams <pointlessjon at me.com>wrote:

>     Date.setLocalTimezone('America/Los_Angeles')
>     Date.getLocalTimezone()

Since ES Dates represent single points in time (you can't have a time
without a date or vice versa), there is no real reason to carry along a
timezone string with each Date instance. This is why I took the approach of
having a static method to simply construct a shifted Date into a particular
timezone. Once the Date object is in that timezone, there is no need to
preserve the timezone string because there can only be one valid offset for
it. You only need to preserve the timezone string when storing a recurring
date/time and ES does not have any native representation of such a thing.
Also, sometimes you do need to preserve the static offset because a
timezone string is not provided. Parsing a SMTP mail header timestamp is an
example of this.

Keeping simple offset storage for a Date makes sense. Then there can be
higher level functions which allow you to create Dates in a particular
timezone or convert between two timezones by manipulating the stored
offset. Yes, someone can resort to manual offset fudgery and create DST
bugs, but hiding offset away would prevent people who *do* know what
they're doing what they need.

-Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130220/a7b17f3e/attachment.html>