In any case, we have an issue because the behavior of the Date and Month is
different
-- Pavel
2017-11-20 9:16 GMT+01:00 Sven Van Caekenberghe <s...@stfx.eu>:
>
>
> > On 20 Nov 2017, at 07: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.
>
> Well, that example is exactly why you do need the TZ (in the date or not
> is another matter). If I, from my TZ, want to be the first to wish you a
> happy birthday, I have to know your exact TZ.
>
> We can discuss about this ad infinitum. I think we all agree that there
> are 2 views (abstract calendar date and concrete time interval/span, which
> requires a TZ), as well as 2 possible ways to deal with the second case (TZ
> inside date or as context outside of the date).
>
> Right now, it is TZ inside, but you are free to ignore it. That is how it
> is, I did not write it, I would probably do it differently myself, but I
> don't think there is a bug, nor that we have to change it any time soon.
>
> There are several alternative packages out there, and everyone can write
> their own, maybe one will eventually become the most popular as to be the
> default in the image, but I doubt it.
>
> > 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?
> >
> > 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
>
>
>
