KDateTime: new revised version

[David Jarvie]

On Friday 25 November 2005 11:30, Shaheed wrote:
>On Thursday 24 November 2005 13:13, Nicolas Goutte wrote:
>> > The problem is that "-0500" does not convey enough information to allow
>> > one to know what that implicit timezone is. One could make some guess
>> > that "-0500" describes a local time near the East Coast, but one cannot
>> > be sure what the timezone is in which the local timestamp originated.
>>
>> Well, when I look in /usr/share/zoneinfo I see that there is a directory
>> Etc with many numbered timezones.
>
>Right. But look at the sizes of those files compared to more normal ones: mine 
>range between 56 and 59 bytes because these are not what one might think of 
>as normal "user" timezones, based on geopolitical boundaries. AFAICS, they 
>are simply reflecting the (military-style) convention of splitting the world 
>up into 24 one hour zones by longitude.
>
>> So I suppose that at least somebody thinks too that numbered timezones are
>> good enough. (However I would prefer a solution without needing the
>> presence of such timezone data files.)
>
>Maybe your latter comment is the key here. Do I understand correctly that you 
>would be happy to take, say,
>
>     1-Jan-2006 17:00 (-0500)
>
>and have that treated as
>
>    1-Jan-2006 12:00 GMT
>
>where the "GMT" is merely a statement of the addition of the offset, and 
>implies nothing about the location of the user? If so, then I suggest this 
>has nothing to do with KTimezones.

>> > I think a key difference here is that Nicolas seems to be thinking of
>> > timestamps generated and manipulated locally, whereas David seems to be
>> > thinking of timestamps generated in one place and used somewhere else.
>>
>> Yes, perhaps. But when the date is used somewhere else, it needs to be
>> processed there too. (For example KMail, calculates a date here, but
>> another KMail needs to read it again there.)
>>
>> May be my comments were more about processing already exisiting dates, but
>> for my use case of KBabel, I need too to create a date from the current
>> date/time and write in the saved Gettext PO file. And KBabel's catalog
>> manager will need to read that date again (and probably another too). And
>> whatever loading and saving it will be with a numeric offset (except very
>> old PO files). However I suppose that the user would prefer his/her local
>> time displayed but at load the date in the file will be in any arbitrary
>> numeric offset. As for saving, Gettext PO files are traditionally saved
>> with the local date/time of the user (including numeric offset). (Sure may
>> be the offset/timezone could be invalid in a file and to be able to keep
>> the date neveretheless could be an interesting idea (while indicating an
>> unknown timezone to the user).)
>
>As I suggest above, if we treat the "-0500" simply as an offset from GMT, with 
>no reference to timezone (or KTimezone*), doesn't this use case work exactly 
>as one might expect?

I earlier today proposed that KDateTime should be able to store an offset from UTC (so as to 
retain information from ISO 8601 strings), and Nicholas thought that this should be treated as 
a local time, not as UTC. But I agree with what you say above, and I think that the "UTC with 
offset" variant should simply be treated as UTC. The KDateTime class should treat the offset 
merely as a comment, and only use it in the toString() method.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html