On 20 November 2017 at 08:30, Ben Coman <b...@openinworld.com> wrote: > I don't ponder much on Dates, DateTimes etc, but I just had one interesting > image flash through my head > and was curious how correct it sounds, or if I'm completely off base. > > So who remembers the old arcade game "Moon Buggy" ? > https://www.youtube.com/watch?v=6EptD9Egf7w > > Now imagine that passing beneath your wheels is a hyper-fast terrain of > DateTime . > Levels are days marked "A" , "B", "C", "D", "E" at *fixed* points on the > DateTime terrain, representing when a particular Date begins. > > As your day progresses dealing with obstacles in your path the *point* of > Date separation approaches you. > In your own timezone you know what Date it is by when your wheels pass over > a Date marker.
I'm just glad that Bloc is on the way and we have GTInspector so that in future when I inspect a Date there'll be a tab there that *you* wrote with a moon buggy flashing lasers to show me what's happening. :-) > Now if someone in the US wants to know the date in New Zealand, > that is like attaching a scanning laser beam to the front of the buggy. > How far ahead it scans depends on the *difference* between time zones. > As the DateTime terrain passes beneath your wheels, the fixed Date point > approaches you, and when it touches your lazer scanner, the Date changes in > the other timezone. > > So the way to find the date in another timezone, > is not to give a Date a timezone, but rather to add the difference in > timezones to your DateTime > to get the DateTime in the target country to compare that with > timezoneless-Date. I think that there's still use for representing a date as a timespan, i.e. a 24 hour period that we can use to find the intersection of times, etc (in addition to adding a timezone offset to a DateTime to figure out the date in a different country). Whether it needs to be a separate class from Timespan I'm not so sure. Cheers, Alistair > cheers -ben > > > > > [1] https://www.youtube.com/watch?v=6EptD9Egf7w > > > On 20 November 2017 at 10:12, David T. Lewis <le...@mail.msen.com> wrote: >> >> Richard, >> >> That is a very good explanation, and 100% correct. >> >> Dave >> >> On Mon, Nov 20, 2017 at 12:30:38PM +1300, Richard A. O'Keefe wrote: >> > I think the fundamental question is what a Date is supposed >> > to represent. I have spent a LOT of time thinking about date >> > and time classes over the last 10 years, and have come to the >> > conclusion that it makes no sense to view a Date as a Timespan. >> > >> > Let's take an example. >> > Christmas this year is going to be 2017-12-25 in every country >> > that uses the Gregorian calendar and observes Christmas at all. >> > If I ask the question >> > "Is Christmas on the same date in Utah as it is in Otago?" >> > I expect to get the answer YES. >> > But if I ask the question >> > "Is the span of time *called* Christmas day there same >> > as the span of time *called* Christmas day here?" >> > I expect to get the answer NO. >> > >> > It's not entirely unlike the way that '95 Hanover Street' >> > is the same street address in my city as '95 Hanover Street' >> > in Edinburgh, but they correspond to quite different places. >> > (Here: the Urgent Doctors; there: serviced apartments.) >> > >> > Returning to Dates, I expect something like >> > aDate asTimespan: aTimeZone >> > to return a timespan that might be 23, 24, or 25 hours >> > (possibly plus an extra second), with *maybe* >> > aDate asTimespan >> > meaning >> > aDate asTimespan: TimeZone here >> > >> > Naturally the same goes for Weeks, Months, and Years, should >> > they exist. >> > >> >
