KDateTime: new revised version

[Shaheed]

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.

> But that was not really the problem here. We were talking about local
> times.
>
> When you have a local time, it is not a time with an unknown time zone.
> There is a difference between the two concepts.

No, a local time is a time with a known offset only, just like the numbered 
files you found. 

> > > Also by making local time being an unknown timezone, this class behaves
> > > differently than from the C library and from QDateTime.
> >
> > I'm not sure that either the C RTL or Qt can take a timestamp which came
> > from the East Coast ("-0500") and convert it into a {datetime, timezone}
> > when the computer on which the library is executing is not the one where
> > the timestamp originated.
>
> Here we were not talking about converting arbitrary numeric timezones but
> we were talking about the concept of "local time".
>
> Qt4's QDateTime has:
> QDateTime QDateTime::toUTC () const
> QDateTime QDateTime::toTimeSpec ( Qt::TimeSpec specification ) const
> QDateTime QDateTime::toLocalTime () const
>
> So Qt4 does *not* consider local time as being without time offset. (As for
> Qt3, we could perhaps argue on this point.)
>
> And in the C library you have localtime(3) and gmtime(3). And there is also
> mktime(3) will convert a local date into the correct offset since the epoch
> (which is UTC).

Yes, both the C RTL and, I assume, Qt 4 take the *current offset* of the 
timezone setting into account. But once reduced to an offset, you cannot 
infer the timezone.

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

Thanks, Shaheed