<div dir="ltr">On Wed, Feb 20, 2013 at 11:03 AM, Jonathan Adams <span dir="ltr"><<a href="mailto:pointlessjon@me.com" target="_blank">pointlessjon@me.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Date.setLocalTimezone('America/Los_Angeles') <br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>Date.getLocalTimezone()</div></div></blockquote><div><br></div><div style>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.<br>
<br>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.</div>
<div style><br></div><div style>-Andrew<br></div></div></div></div>