On 20 November 2017 at 08:30, Ben Coman <btc@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 <lewis@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.