Replacement for KDateTime

[Dāvis Mosāns]

2015-08-11 0:37 GMT+03:00 David Jarvie <djarvie at kde.org>:
> On Mon, August 10, 2015 11:31 am, Dāvis Mosāns wrote:
>> 2015-08-10 11:34 GMT+03:00 John Layt <john at layt.net>:
>>> On 9 August 2015 at 17:26, Dāvis Mosāns <davispuh at gmail.com> wrote:
>>>>
>>>>
>>>> When I implement date/time related things I always use timestamps in
>>>> UTC everywhere
>>>> and when need to display to user or pass to some API then convert to
>>>> respective
>>>> format and timezone. Any other way makes it only more complicated.
>>>
>>>
>>> That works well when recording the time something occurred at, i.e. in
>>> the
>>> past, but it just doesn't work for events scheduled in the future when
>>> the
>>> time zone rules could change for both the source of the event and in any
>>> observers location. For example, if I'm in UTC+2 and I schedule a
>>> meeting
>>> every Monday  at 10am for the next 2 years, and the government changes
>>> the
>>> time zone rule from UTC+2 to UTC+3, if I stored the event time in UTC
>>> then
>>> my meeting has suddenly changed from 10am to 11am! If someone in the New
>>> York office phones in to the meeting, and their time zone rules change
>>> relative to UTC then they also get the wrong time. The only workable
>>> solution is to store the event in local time zone for the event location
>>> (unless they explicitly want UTC), and then convert it to the
>>> destination
>>> time zone at the last possible moment.
>>>
>>
>> Indeed, I hadn't thought about this. Basically there's 2 types of time,
>> one
>> is distinct fixed time point (I've worked only with these) and other
>> is human time
>> which doesn't really represent a distinct time because it might change
>> relative
>> to UTC.
>> So if I set event to see solar eclipse I need to set it in UTC as
>> otherwise it will
>> be wrong when timezone or DST changes. But for meetings and other similar
>> things need it in human time as it doesn't matter that current 10am
>> actually isn't
>> that that same 10am when it was set. Also thinking about this I
>> realized that for
>> human time you don't need timezone but actually a place, location. Because
>> as you said timezone can change and it only depends on location. So to
>> convert time between different locations you need to get current timezones
>> for
>> both locations. Timezone when event was set is useless because it might
>> have changed by now. So basically need to store time in either UTC or with
>> human time and location. Also location should be as precise as possible
>> because theoretically country can split and each part change to
>> different timezone.
>
> I think you misunderstand what is meant by time zone as defined by
> iCalendar and as it is used in the other mails in this thread. It means
> the set of offsets from UTC used officially in a country or region and
> when they apply, and how this changes over the years. In many locations,
> the time zone therefore defines UTC offsets for summer and winter and the
> dates and times in each year when the transitions between winter and
> summer time take place. I.e. a time zone is essentially what you refer to
> as "human time".
>

Kinda, with timezone I meant it in form of plain offsets like +02:00 and that's
useless because that doesn't really tell anything.
Also timezones as implemented in Windows are bad because there same time
zone is used for multiple regions/countries. That's why I said you need a
location for human time (and not timezone like +02:00) and no, human time isn't
same as timezone, as I could have alarm set at 10:00 (human time) without any
timezone information so that even when moving countries (and changing clock
timezone) alarm still would be at 10:00 local time.

I didn't mentioned how such location to timezone mapping could be implemented
but everyone probably knows that tz database is actually such mapping.
Europe/Berlin is a location in Germany and it represents all timezone offsets
used there for various timezone periods. Also I was speculating that location
should be very precise because theoretically for example currently if user lives
in Düsseldorf and you're using Europe/Berlin timezone (which is correct now) but
then Germany decides to use different timezones for different parts of country,
say new timezone Euopre/Düsseldorf, that user now will have incorrect old
timezone for events, etc.  but if you store city and then map city to
timezone it all
would work as long as you've up-to-date mappings.

Seems currently time zone is quite ambiguous word and shouldn't use it to mean
time zone offset (but then again, that's what it is...), it's also
ambiguous because
it can refer to different time zone implementations (eg. like Windows vs tz
database).