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