> 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
}.
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
>>>
>>
>>
>
