Re: wxDateTime and daylight savings...
Chris.Barker
> Oh boy...
you're right there.
> The picture is far more complicated than that.
Well, yes -- and while I"d love a really comprehensives system, and
half-baked one is worse than a simple one, and that's what wx has now.
> "Turn DST off" is nowhere near sufficient to deal with the world's
> timekeeping.
Of course not, but at least it would give the user control, which we
don't have now.
> Instead, what you need is machinery that divides the world
> into several hundred regions (not just the 24 "timezones" that you might
> think you need).
except, I, indeed, know what I need, and it's not the whole world. I
need the coastal US, which is a handful of time zones, and not,
thankfully, Arizona.
> A "turn off
> DST" knob is most definitely the wrong way to go.
I disagree here -- when we're crossing DST boundaries, we want plain old
simple time, without a discontinuity -- even if we're in a region that
does follow DST time.
As it stands now, I can't even do UTM right, 'cause it will assume that
I'm in the systems timezone, and therefore DST. Granted, if we did have
the full database, and a way to specify a zone, then i could specify
UTM, and all would be well.
But short of the full solution, turning it off would let me roll my own,
simple use-specific version.
> I would suggest that wx should use the OS time machinery, especially on
> Unix platforms.
my understanding is that wx uses the system calls where it can, and
rolls it's own where the system calls aren't there. It seem sit uses
system calls for formating, that respect the system time zone, and rolls
its own for GetDSTStart - is there no standard system call for that?
> If for some reason it wants its own, it should use the
> Olson database and support library.
Well, I'm all for a comprehensive and correct solution, but baring that,
a little more control would really help. You wouldn't believe how ugly
our code is to work around all this!
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Christopher Barker
> I'm not sure we'll have time to do a patch --
OK -- it just wasn't that much work!
Enclosed is datetimetest.cpp and datetime.cpp
These were edited from the wxMac 2.8.9 tarball. I don't have wx SVN all
set up, so I can't do a proper patch.
I also am not set up to run CPP Unit, so I haven't run the tests, but I
put the dates in for 2005 - 2009.
If you really need it as a proper patch, I can try to do that next week.
This only patches the GetStartDST and GetEndDST -- I'm not going to do
anything else unless folks can agree on what to do (and I can find the
time!)
thanks,
-Chris
Vadim Zeitlin
CB> OK -- it just wasn't that much work!
Glad to hear it!
CB> Enclosed is datetimetest.cpp and datetime.cpp
CB>
CB> These were edited from the wxMac 2.8.9 tarball. I don't have wx SVN all
CB> set up, so I can't do a proper patch.
CB>
CB> I also am not set up to run CPP Unit, so I haven't run the tests, but I
CB> put the dates in for 2005 - 2009.
CB>
CB> If you really need it as a proper patch, I can try to do that next week.
I'd really prefer if you could do it and also attach it to Trac ticket so
that it doesn't get lost. I can't test (and hence apply) it immediately
anyhow so the next week will definitely be fine.
TIA!
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Christopher Barker
> Thanks, the tests do pass (even after I modified the code to also test the
> years after 2004 :-)
Didn't my patch include tests for 2007, 2008, 2009? oh well, sorry to
make you do that.
> so I've checked it in now (in both 2.8 and trunk).
great, thanks!
> CB> Anyway, as wx does it now (2.8.9 anyway), a DateTime object is
> CB> apparently ALWAYS in local time, as determined by the system.
>
> I still don't quite agree with this. wxDateTime object is basically
> timezone-agnostic, it's up to you to interpret it.
A full features system would be TZ aware, but I'm well aware of the
challenge of that, so TZ agnostic is fine, except:
> But it does seem that we
> do interpret it always in local TZ when converting it to string.
which is killing us.
and when calling ToTimezone() or MakeTimezone()... If it were TZ
agnostic, you would need to specify both from and to timezones to do any
time zone shifting...
> I agree, providing "tzFrom" argument to these functions would be helpful.
I would argue critical -- the way it is now is almost useless.
> CB> 2) wxDateTime::Format
> CB>
> CB> This is what's killing us -- I think the ticks calculations are fine,
> CB> but when you try to format, it always assumes local time, and so always
> CB> applies DST -- there is no way to just use standard time , or UTC , or..
>
> Wait, and what happens if you use ToTimeZone() before calling Format()? I
> do agree that it may be more convenient to add a tz parameter directly to
> Format() but the same result should be obtained by calling ToTimeZone()
> first, shouldn't it?
no, because, as you said, a DateTime object is TZ agnostic -- after
calling ToTimeZone, all that has been done is had some hours added or
subtracted -- the DT object still thinks it's in local time, because
that's all it can be!
And yes, I did try all possible combinations of this -- that's what's
been so frustrating -- I kept thinking that I could use the T
Z stuff built in to DateTime, but no, it just doesn't help.
NOTE: you can pass in a TZ parameter to Format, ,but all it does is add
or subtract the hours, and then still format for the local TZ! In fact,
IMO, the TZ parameter to Format should not change the time, but rather
simply format the DT in an appropriate way for that TZ -- can you call
strftime() with a specific time zone in this way?
You seem to be going through the same process as I did -- I kept
thinking there MUST be a way to make this useful -- but I really
couldn't find it.
Anyway, thanks for applying the patch, and looking at these issues.
Vadim Zeitlin
CB> Vadim Zeitlin wrote:
CB> > Thanks, the tests do pass (even after I modified the code to also test the
CB> > years after 2004 :-)
CB>
CB> Didn't my patch include tests for 2007, 2008, 2009? oh well, sorry to
CB> make you do that.
You did add the tests but the loop was only going from 1990 to 2004 so
they were not taken into account. Hence the smiley above.
CB> NOTE: you can pass in a TZ parameter to Format, ,but all it does is add
CB> or subtract the hours, and then still format for the local TZ! In fact,
CB> IMO, the TZ parameter to Format should not change the time, but rather
CB> simply format the DT in an appropriate way for that TZ -- can you call
CB> strftime() with a specific time zone in this way?
Unfortunately you can't. We'd need to either change the time zone
temporarily which is not really acceptable in MT programs or never use
strftime() for non-local TZ. We do reimplement most of strftime() already
so it shouldn't be too difficult to do the latter but it's still quite some
work. In particular we'd need to implement %X and %Z formats somehow.
CB> You seem to be going through the same process as I did -- I kept
CB> thinking there MUST be a way to make this useful -- but I really
CB> couldn't find it.
Yes, I do think I see the problem now. It seems clear that we need to add
a "tzFrom" parameter to To/FromTimezone() and this should be easy to do,
you just need time to write the tests to ensure you didn't subtract instead
of adding or something like this. But fixing Format(tz) is more difficult.
Still it needs to be done so please do open a Trac ticket for it -- while I
don't promise at all to work on this in the near future, we still need to
record the problem to at least avoid having the same discussion in a couple
of months or years.
Thanks,