On 20 November 2017 at 14:58, Alistair Grant <akgrant0...@gmail.com> wrote:
> On 18 November 2017 at 18:38, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> >
> >
> >> On 18 Nov 2017, at 17:46, Alistair Grant <akgrant0...@gmail.com> wrote:
> >>
> >> On 17 November 2017 at 14:44, Sven Van Caekenberghe <s...@stfx.eu>
> wrote:
> >>> Both interpretation are correct and valid, it is just hard to capture
> them with one class.
> >>>
> >>> In normal human conversation and in the abstract, of course a date is
> just a year/month/date triple. But that is because most people only look at
> this from their own perspective. However, from an international
> perspective, of course it must include time zone info. Remember
> end-of-year/new-year, with all those articles about people in other
> countries partying or having fireworks earlier/later.
> >>>
> >>> Date transitions are different in each time zone, so to talk
> accurately about a date, you need the context of a time zone.
> >>
> >> I don't think this is correct.
> >>
> >> If we take CEST (UTC+1) and AEDT (UTC+11) as an example: From midnight
> >> to 14:00 UTC the dates are the same. From 14:00 - 24:00 CEST
> >> Australia is one day ahead.
> >>
> >> How can this be interpreted sensibly given only a date? Unless I'm
> >> missing something, I think Peter is correct and that a Date shouldn't
> >> have any concept of timezone.
> >
> > Inspect and compare the following two Dates:
> >
> > {
> > (DateAndTime fromString: '2018/01/01T00:00:00+11') asDate.
> > (DateAndTime fromString: '2018/01/01T00:00:00+01') asDate
> > }.
> >
> > This is as if you typed 'Date today' at the beginning of next January
> 1st in your timezone or mine. Both print as '1 January 2018'. In some sense
> they are equal (the abstract, context free view), but as a timespan
> [start,stop] interval they are different, they do not include the same
> points in time. By having the timezone in there, the ambiguity is resolved.
> That is because the exact start moment is different:
> >
> > {
> > (DateAndTime fromString: '2018/01/01T00:00:00+11') asUTC.
> > (DateAndTime fromString: '2018/01/01T00:00:00+01') asUTC
> > }.
>
> Sven, thanks for your reply. I haven't thought about this as much as
> Richard, but came to the same conclusion.
>
> I think your comment about being equal "in the abstract, context free
> view" gets to the core of the issue.
>
> A date can be abstract, i.e. just a day, month and year, or it can be
> a timespan (a 24 hour period starting at a particular timezone). We
> may know the appropriate timezone when we specify the date, or we may
> not know until we want to use the date.
>
> As an example, take wishing someone happy birthday. I want to know
> that person's birthday in the abstract. Each year I will want to
> apply it with timezones, i.e. I'll figure out an appropriate time to
> contact them given my timezone and their's. Figuring out when to
> contact them certainly doesn't depend on the timezone I was in when I
> recorded their birthday, or the timezone they were in when they were
> born. If I want to know if that person and I have the same birthday,
> I won't be taking timezones into account.
>
Nice examples. They made a lot of sense.
>
> Google Calendar has (had?) exactly this problem. I entered an all day
> event as a reminder for someone's birthday. When the day came I
> happened to be in a different timezone and their birthday was from 4pm
> one day to 4pm the next. I don't remember which timezone I was in
> when I added the event, and I'm certainly not interested in figuring
> it out. Which of the two dates covered by this "one date" is
the correct one?
>
Obviously GodGoog should know this date was associated with a particular
person,
and since they're happy with GG geo-tracking their location, GG should have
adapted.
Sounds like a bug to me.
\
;^)-cheers-ben
/
>
> It should be easy to convert an abstract date to a concrete date, i.e.
> one with a specified timezone, but I think they are two different
> concepts.
>
> Thanks!
> Alistair
>
>
>
>
> > BTW, my ZTimestamp package is an alternative DateAndTime object that is
> (1) always in UTC, and thus contains no timezone and (2) has second
> precision. It is half the size and faster to work with.
> >
> > By using its accompanying ZTimezone class that loads the Olsen DB, you
> do the necessary conversions when presenting to humans. That of course then
> requires the context (current or applicable timezone) to be supplied
> externally.
> >
> > (ZTimezone id: 'Australia/Sydney') gmtToLocal: ZTimestamp now.
> >
> > HTH,
> >
> > Sven
> >
> >> Cheers,
> >> Alistair
> >>
> >>
> >>> Whether that timezone is actually part of the date object is another
> discussion, but there is always the timezone context even if it is implicit
> ('of course I mean my own timezone and not yours').
> >>>
> >>>> On 17 Nov 2017, at 14:19, Peter Uhnák <i.uh...@gmail.com> wrote:
> >>>>
> >>>> Because Date has, by definition, no concept of time.
> >>>> The only reason why you see it is because someone decided to save a
> bit of time and reuse implementation.
> >>>>
> >>>> If you want to move TZ, you need something that _has_ time. Such as
> DateAndTime.
> >>>>
> >>>> You can also read the comments ...
> >>>>
> >>>> Date
> >>>>> Instances of Date are Timespans with duration of 1 day.
> >>>>
> >>>> it represents an entire day, not a particular time point
> >>>>
> >>>> DateAndTime
> >>>>> I represent a point in time or timestamp as defined by ISO 8601.
> >>>>> I am TimeZone aware.
> >>>>
> >>>> I really don't understand why are you trying to force TZ into Date
> against it's purpose when you have a class that does exactly what you want
> and was built for that purpose.
> >>>>
> >>>> Peter
> >>>>
> >>>> On Fri, Nov 17, 2017 at 12:09 PM, Prof. Andrew P. Black <
> bl...@cs.pdx.edu> wrote:
> >>>>
> >>>>> On 17 Nov 2017, at 08:49 , Peter Uhnák <i.uh...@gmail.com> wrote:
> >>>>>
> >>>>> I find the concept of translating TZ of a Date silly. The real bug
> imho should be that it prints both time and TZ.... this is Date, not
> DateAndTime.
> >>>>>
> >>>>
> >>>> I live in Oregon, and frequently work with people in New Zealand,
> which is (depending on the time of year) 19 to 21 hours ahead of Oregon.
> So, when it is 3pm at home, it is noon the next day in New Zealand.
> >>>>
> >>>> This means that in order to know the day of the week, the month, and
> even the year, of a given instant in UTC, one has to know the timezone that
> is being referred to. The answer could be Sunday, 31 December 2017 for one
> observer, and Monday, 1 January 2018 for another.
> >>>>
> >>>> So, contrary to your statement, I don’t see how I can know the date
> without also knowing the Time Zone.
> >>>>
> >>>> Andrew
> >>>>
> >>>
> >>>
> >>
> >
> >
>
>
