Replacement for KDateTime

[David Jarvie]

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

-- 
David Jarvie.
KDE developer.
KAlarm author - http://www.astrojar.org.uk/kalarm