<div class="gmail_quote">On Thu, Feb 2, 2012 at 2:50 PM, Yanni Chiu <span dir="ltr"><<a href="mailto:yanni@rogers.com">yanni@rogers.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 02/02/12 11:25 AM, Chris Muller wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best to strip all Dates (NOT DateAndTimes) of their timezone.<br>
</blockquote>
<br></div>
IMHO, there are two different concepts getting mixed up.<br>
<br>
1) There is a "date", which has a day, month and year (and calendar). If you're modeling dates to be printed on a 12-month calendar that can be used anywhere in the world, then this is the kind of date you want.<br>
<br>
2) There is the 24hr period (sometimes 23hr or 25hr) which corresponds to that "date". This 24hr period is timezone dependent. If you're making a scheduling application, then this is the kind of date you need.<br>
</blockquote><div><br></div><div>I assume that's what a Timespan is for, the superclass of Date.</div><div><br></div><div>Actually, it looks to me like we're missing a class. Perhaps we should have a "Day", which represents that 24 hour period, since we have similar classes for Week, Month, and Year, which are also all Timespans. That would allow Date to represent #1 above.</div>
<div><br></div><div>Thoughts?</div><div><br></div><div>- Jon</div><div><br></div></div>