wxDateTime and daylight savings...
Christopher Barker
wx 2.8.9
I hope I'm missing something, but it appears wxDateTime is broken with
respect to daylight savings. Daylight savings is a nightmare, but while
I'd like to ignore it, I can't, and wxDateTime doesn't let me just
handle it myself.
A couple issues:
1) ::GetBeginDST() and ::GetEndDST() are reporting the wrong results
DST start: Sun Apr 5 02:00:00 2009
DST end: Sun Oct 25 02:00:00 2009
I think these are probably right from before the US changed it in 2007:
http://aa.usno.navy.mil/faq/docs/daylight_time.php
This is a simple bug.
2) while wxDateTime reports the start and end wrong, it actually makes
the change at the right time:
Sun Mar 8 00:05:00 2009 tics 1236499500 hours 343472 DST: 0
added: 1 hours
Sun Mar 8 01:05:00 2009 tics 1236503100 hours 343473 DST: 0
added: 2 hours
Sun Mar 8 03:05:00 2009 tics 1236506700 hours 343474 DST: 1
so it's skipping from 0200 to 0300 on March 8 -- which is correct.
I think the discrepancy is that ::GetStartDST() is using wx code that
has not been updated, whereas the string formating code is using system
calls, that have been updated. However, having them out of whack makes
it very hard to work with.
Now the design issues -- it doesn't seem possible to turn off DST. There
are times and place when you want DST, and times and places when you
don't, and you can't always rely on system settings to get it right.
For instance, we're working with an app that displays time series of
data. If the time period we are looking at spans a DST change, we'd like
the user to be able to specify if they want the data in daylight or
standard time, but we can't get wxDateTime to do that. In this case, we
have the start time, and want to be able to add wxTimeSpans to it, and
then format it to be human readable. wxDateTime makes that very easy,
except that it goes all to heck with DST.
Also, there is some support for time zones, but it appears that
wxDateTime always assumes it's in the system local time zone, so if you
make a timezone change:
wxDateTime::MakeTimezone or wxDateTime::ToTimezone
it always calculates the shift from the local system settings -- again,
this wreaks havoc with DST, and isn't really useful anyway -- sometimes
you need to know what timezone you're using, and it's not always the
machine setting.
I've written a little wxPython script to test/demo some of this. Here
are the results (script enclosed):
Checking GetBeginDST
DST start: Sun Apr 5 02:00:00 2009
start: Sun Apr 5 01:00:00 2009
plus 2 hours: Sun Apr 5 03:00:00 2009
DST end: Sun Oct 25 02:00:00 2009
start: Sun Oct 25 01:00:00 2009
plus 2 hours: Sun Oct 25 03:00:00 2009
no changes over when it thinks it's DST change.
however, there is a shift here:
start: Sun Mar 8 01:00:00 2009
plus 2 hours: Sun Mar 8 04:00:00 2009
It made the DST shift
checking changing time zone
local (PST): Sat Feb 7 12:00:00 2009 1234036800 342788
shifted to UTC: Sat Feb 7 20:00:00 2009 1234065600 342796
shifted back to PST: Sat Feb 7 20:00:00 2009 1234065600 342796
Oops -- it didn't shift back, 'cause it thinks its already in PST
Is there any hope of getting this cleaned up?
I think we need the following:
The ability to tag a DateTime with a time zone -- so when you convert
around you get the right thing
The ability to turn of DST, if you don't want it -- setting a TimeZone
to either, say, PST or PDT should do that right,
If nothing else, turning off DST is really key, then I can just handle
it myself.
-Chris
--
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
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
Paul Koning
> I hope I'm missing something, but it appears wxDateTime is broken with
> respect to daylight savings. Daylight savings is a nightmare, but
while
> I'd like to ignore it, I can't, and wxDateTime doesn't let me just
> handle it myself.
>
> A couple issues:
>
> 1) ::GetBeginDST() and ::GetEndDST() are reporting the wrong results
>
> DST start: Sun Apr 5 02:00:00 2009
> DST end: Sun Oct 25 02:00:00 2009
>
> I think these are probably right from before the US changed it in
2007:
>
> http://aa.usno.navy.mil/faq/docs/daylight_time.php
>
> This is a simple bug. ...
>
> Now the design issues -- it doesn't seem possible to turn off DST.
> There
> are times and place when you want DST, and times and places when you
> don't, and you can't always rely on system settings to get it right.
The picture is far more complicated than that.
"Turn DST off" is nowhere near sufficient to deal with the world's
timekeeping. 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). The difference among these regions isn't primarily the
offset from GMT, but rather the rules for when (if ever) DST is in
effect, and how those rules have changed over the years. A "turn off
DST" knob is most definitely the wrong way to go. The right way is to
have a way to say "let me have the time by the rules of the state of
Arizona" (which translates to MST year around), or "the rules of
Melbourne, Australia" (which has DST in what us USians would think of as
winter, and the rule was different in 2008 (I think) than in other
years).
The systematic way to do this is with the "Olson database" maintained by
Arthur Olson of NIST, and incorporated as a standard mechanism in many
Unix systems (such as Linux). Those databases changes several times a
year. Windows has a limited subset of this mechanism, as far as I can
tell, and Java also has something similar but unfortunately separate and
not usually as closely updated.
I would suggest that wx should use the OS time machinery, especially on
Unix platforms. If for some reason it wants its own, it should use the
Olson database and support library. That will do the job
comprehensively and correctly. You do need up to date databases, of
course. The 2007 US rule change was in the Olson database a year or two
ahead of time, but not everyone sent out that change when it became
available.
paul
Vadim Zeitlin
CB> 1) ::GetBeginDST() and ::GetEndDST() are reporting the wrong results
CB>
CB> DST start: Sun Apr 5 02:00:00 2009
CB> DST end: Sun Oct 25 02:00:00 2009
CB>
CB> I think these are probably right from before the US changed it in 2007:
CB>
CB> http://aa.usno.navy.mil/faq/docs/daylight_time.php
CB>
CB> This is a simple bug.
Indeed, this code hasn't been updated since being written. It would be
nice if you could make a patch implementing the new DST rules for the USA.
Otherwise please open a bug about it.
CB> 2) while wxDateTime reports the start and end wrong, it actually makes
CB> the change at the right time:
This is because -- as you correctly noted yourself in another message --
wx uses the system API for this while it uses its own code to determine the
DST start/end.
CB> Now the design issues -- it doesn't seem possible to turn off DST.
I don't really know how much sense would this make. DST (unfortunately)
must be taken into account whenever you speak about time in local time
zone. The only way to avoid DST is to always use UTC time but this would
hardly be very convenient.
CB> For instance, we're working with an app that displays time series of
CB> data. If the time period we are looking at spans a DST change, we'd like
CB> the user to be able to specify if they want the data in daylight or
CB> standard time, but we can't get wxDateTime to do that.
How would you do that if wxDateTime had no DST support at all?
CB> Is there any hope of getting this cleaned up?
There is always hope but unfortunately I have no immediate plans (nor
possibility to be honest) to work on this. So while I'd help as much as I
can anybody brave enough to try to improve DST/TZ handling I can't promise
doing anything myself, sorry.
CB> I think we need the following:
CB>
CB> The ability to tag a DateTime with a time zone -- so when you convert
CB> around you get the right thing
I'm not sure I agree with this one as this opens a whole new can of worms:
just think of how (almost?) all operations on wxDateTime would need to be
affected and redefined by this. I think it's up to the program to know
which timezone it considers the given wxDateTime object to be in.
CB> The ability to turn of DST, if you don't want it -- setting a TimeZone
CB> to either, say, PST or PDT should do that right,
CB>
CB> If nothing else, turning off DST is really key, then I can just handle
CB> it myself.
I agree that current handling of DST is far from perfect but I don't see
how would turning it off help you with your particular problem. Maybe what
you really need is to manually override the start/end DST dates?
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Christopher Barker
> CB> I think these are probably right from before the US changed it in 2007:
> CB>
> CB> http://aa.usno.navy.mil/faq/docs/daylight_time.php
> CB>
> CB> This is a simple bug.
>
> Indeed, this code hasn't been updated since being written. It would be
> nice if you could make a patch implementing the new DST rules for the USA.
I'm not sure we'll have time to do a patch -- we've already done the
kludgy work-arounds we needed, and need to put this project to bed --
but maybe!
> Otherwise please open a bug about it.
Done:
http://trac.wxwidgets.org/ticket/10425
I may have categorized it wrong -- I put it in base.
> This is because -- as you correctly noted yourself in another message --
> wx uses the system API for this while it uses its own code to determine the
> DST start/end.
I guess the question is -- is there a system call to get the DST time
change -- it seems that would be more reliable.
> CB> Now the design issues -- it doesn't seem possible to turn off DST.
>
> I don't really know how much sense would this make. DST (unfortunately)
> must be taken into account whenever you speak about time in local time
> zone. The only way to avoid DST is to always use UTC time but this would
> hardly be very convenient.
However, the current way does not let you use UTC at all! It always uses
the local system settings -- this is all well and good when you want o
tell the user when an email message or something was sent, but it's
worthless for doing any kind of time series analysis or display.
We need to be able to present a time series that overlaps the DST
change, and do it without the skipped or repeated times -- this is
impossible with wxDateTime as is is currently written.
> CB> For instance, we're working with an app that displays time series of
> CB> data. If the time period we are looking at spans a DST change, we'd like
> CB> the user to be able to specify if they want the data in daylight or
> CB> standard time, but we can't get wxDateTime to do that.
>
> How would you do that if wxDateTime had no DST support at all?
Then we'd handle DST ourselves -- a pain, but doable.
> CB> Is there any hope of getting this cleaned up?
>
> There is always hope but unfortunately I have no immediate plans (nor
> possibility to be honest) to work on this. So while I'd help as much as I
> can anybody brave enough to try to improve DST/TZ handling I can't promise
> doing anything myself, sorry.
well, OK, someone has to have the time! (pun intended!)
> CB> The ability to tag a DateTime with a time zone -- so when you convert
> CB> around you get the right thing
>
> I'm not sure I agree with this one as this opens a whole new can of worms:
> just think of how (almost?) all operations on wxDateTime would need to be
> affected and redefined by this.
I'm not so sure -- basic tick math would be the same, you "only" need to
change the formatting code -- but hopefully that's a matter of passing
in the TZ to the system code being used already.
Then you'd have to change the ToTimeZone code, but that code is pretty
worthless as it is, and all it would take is an additional addition.
> I think it's up to the program to know
> which timezone it considers the given wxDateTime object to be in.
This is my key point -- as it is written now, this is impossible! All I
can do is use the system time zone! I can pretend it's UTM, but the
formating will still use US Pacific time. This works fine most times
except the DST change-over.
As far as I can tell, I can not get wxDateTime to display:
Sun Mar 8 02:05:00 2009
Because that time does not exist in my timezone!
I'm going to repeat this, 'cause it's my key point:
> CB> If nothing else, turning off DST is really key, then I can just handle
> CB> it myself.
If it's possible to use the system calls this way, then that should be
easy -- it looks like the struct tm has a tm_isdst flag that can be set,
and strftime() has the %Z for time zone, though I don't know where it's
supposed to get that. I'm not sure what mktime does with DST... (I"m
also reading an old copy of K&R, so things may have changed!)
> I agree that current handling of DST is far from perfect but I don't see
> how would turning it off help you with your particular problem. Maybe what
> you really need is to manually override the start/end DST dates?
That would work to.
Thanks for your thoughts.
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!
Vadim Zeitlin
CB> Vadim Zeitlin wrote:
CB> > I'd really prefer if you could do it and also attach it to Trac ticket so
CB> > that it doesn't get lost.
CB>
CB> good idea -- should I do the patch against trunk?
If you have the possibility to do it, please do as it is needed in the
trunk too. The patch should be applied to both 2.8 and trunk normally.
Also, if you haven't read it yet, please see
http://trac.wxwidgets.org/wiki/HowToSubmitPatches for some (hopefully
helpful) instructions.
Thanks again,
Christopher Barker
> I'd really prefer if you could do it and also attach it to Trac ticket so
> that it doesn't get lost.
good idea -- should I do the patch against trunk?
-Chris
Vadim Zeitlin
CB> Done:
CB>
CB> http://trac.wxwidgets.org/ticket/10425
CB>
CB> I may have categorized it wrong -- I put it in base.
No, this is correct, thanks.
CB> > This is because -- as you correctly noted yourself in another message --
CB> > wx uses the system API for this while it uses its own code to determine the
CB> > DST start/end.
CB>
CB> I guess the question is -- is there a system call to get the DST time
CB> change
Not AFAIK. Obviously CRT does know about this but it doesn't seem to
provide any way to find the start/end of DST period other than by checking
all days one by one.
CB> > CB> Now the design issues -- it doesn't seem possible to turn off DST.
CB> >
CB> > I don't really know how much sense would this make. DST (unfortunately)
CB> > must be taken into account whenever you speak about time in local time
CB> > zone. The only way to avoid DST is to always use UTC time but this would
CB> > hardly be very convenient.
CB>
CB> However, the current way does not let you use UTC at all!
I am not sure what exactly is not allowed, could you please explain?
Also, have you noticed "noDST" parameter of To/FromUTC()?
CB> As far as I can tell, I can not get wxDateTime to display:
CB>
CB> Sun Mar 8 02:05:00 2009
CB>
CB> Because that time does not exist in my timezone!
I agree, this would definitely be a problem. But I'd need to have a test
to convince myself that it's indeed the case -- would you already have such
test by chance?
CB> If it's possible to use the system calls this way, then that should be
CB> easy -- it looks like the struct tm has a tm_isdst flag that can be set,
CB> and strftime() has the %Z for time zone, though I don't know where it's
CB> supposed to get that. I'm not sure what mktime does with DST... (I"m
CB> also reading an old copy of K&R, so things may have changed!)
I don't think they did concerning the basic C time support. And %Z and
tm_isdst can both be only used to find the beginning/end of DST if you're
ready to test all the days one by one, as I wrote above. Actually it might
be not such a huge deal, especially as you should be able to cache the
answer, but this just doesn't sound like a very elegant solution :-(
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,
Christopher Barker
> CB> http://trac.wxwidgets.org/ticket/10425
I've now added a patch -- it hasn't been tested, I don't know how to run
the unit tests, but I did add tests for recent years, so it should be
set to go.
> CB> is there a system call to get the DST time
> CB> change
>
> Not AFAIK. Obviously CRT does know about this but it doesn't seem to
> provide any way to find the start/end of DST period other than by checking
> all days one by one.
what a pain...
> tm_isdst can both be only used to find the beginning/end of DST
> if you're ready to test all the days one by one, as I wrote above.
> Actually it might be not such a huge deal, especially as you should
> be able to cache the answer, but this just doesn't sound like a very
> elegant solution :-(
I agree -- not at all elegant -- but it may be more reliable than having
totally separate wx code that we need to maintain, and certainly doesn't
support all time/DST zones.
> CB> > CB> Now the design issues -- it doesn't seem possible to turn off DST.
> CB> >
> CB> > I don't really know how much sense would this make. DST (unfortunately)
> CB> > must be taken into account whenever you speak about time in local time
> CB> > zone.
no, it doesn't -- maybe when you want "local" time, as defined by the
users system settings, but when you want to be able to control the time
zone, you're dead in the water.
> The only way to avoid DST is to always use UTC time..
well, no -- as I think you said before, Time zones are ugly enough that
we kind of have to let the application code control it - the application
needs to be able to know what time zone a given DateTime object
represents. That could be local time, local standard time, local
daylight time, UTC, or, for that matter any other time zone. In our
apps, for instance, we usually use local time, but we can't have a
discontinuity when we cross the DST border, so we want to be able to use
either daylight or standard time for those time brackets.
Anyway, as wx does it now (2.8.9 anyway), a DateTime object is
apparently ALWAYS in local time, as determined by the system. This is
dandy when you want to tell the user when an email was written or
something, but problematic when you are working with time series that
may not represent something going on in that users time zone.
This is an issue in two places:
1) wxDateTime::ToTimeZone and ::MakeTimeZone
These appear to ALWAYS go from the local zone to whatever you specify --
so they are useless if you want your DateTime to represent another TZ --
I can't use them to shift from UTC to PST, for example, which is just
what you'd want to do if you wanted to work in UTC. This isn't such a
big deal, as all is does is add (or subtract) a constant number of
hours, but why have it, if it's so useless? If you're not going have a
DateTime object know its time zone, you should at least be able to
specify a "from" and "to" timezone in ToTimeZone and MakeTimeZone.
2) wxDateTime::Format
This is what's killing us -- I think the ticks calculations are fine,
but when you try to format, it always assumes local time, and so always
applies DST -- there is no way to just use standard time , or UTC , or..
. The short version is:
There is no way to get: Sun Mar 8 02:00:00 2009
> I agree, this would definitely be a problem. But I'd need to have a
> test to convince myself that it's indeed the case -- would you
> already have such test by chance?
Below is some simple test code in Python (we got the same results in C++
with 2.8.9, windows and OS-X) -- note that I'm on a machine in US
Pacific time -- you may need adjust to see the effect on a machine
elsewhere.
wxDateTime::GetTm() doesn't appear to be wrapped for Python, so I
haven't tested that.
Here's the results:
christopher-barkers-power-mac-g5:~/Temp cbarker$ ./test_dt.py
Checking GetBeginDST
DST start: Sun Apr 5 02:00:00 2009
start: Sun Apr 5 01:00:00 2009
plus 2 hours: Sun Apr 5 03:00:00 2009
DST end: Sun Oct 25 02:00:00 2009
start: Sun Oct 25 01:00:00 2009 Sun Oct 25 08:00:00 2009
plus 2 hours: Sun Oct 25 03:00:00 2009
no changes over when it thinks it's DST change. This makes
sense, as that isn't the correcnt DST shift for 2009
however, there is a shift here:
start: Sun Mar 8 01:00:00 2009
start in UTC time: Sun Mar 8 09:00:00 2009
plus 2 hours: in local time Sun Mar 8 04:00:00 2009
plus in UTC time: Sun Mar 8 11:00:00 2009
plus in PST time: Sun Mar 8 04:00:00 2009
plus in PDT time: Sun Mar 8 04:00:00 2009
It made the DST shift
It appears the passing in a tz to Format shifts from local to
the specified time -- no way to specify what time zone the time
represents. I think it really should not specify a desired shift,
but rather specify what TZ that datetime is -- so it can format
correctly for that TZ)
Now try to shift it back two hours:
back in local time: Sun Mar 8 01:00:00 2009
nope - it's done the DST shift again
Try to explicitly set to Sun Mar 8 02:00:00 2009
Sun Mar 8 03:00:00 2009
nope: that did the DST shift!
Vadim Zeitlin
CB> Vadim Zeitlin wrote:
CB> > CB> http://trac.wxwidgets.org/ticket/10425
CB>
CB> I've now added a patch -- it hasn't been tested, I don't know how to run
CB> the unit tests, but I did add tests for recent years, so it should be
CB> set to go.
Thanks, the tests do pass (even after I modified the code to also test the
years after 2004 :-) so I've checked it in now (in both 2.8 and trunk).
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. But it does seem that we
do interpret it always in local TZ when converting it to string.
CB> This is an issue in two places:
CB>
CB> 1) wxDateTime::ToTimeZone and ::MakeTimeZone
CB>
CB> These appear to ALWAYS go from the local zone to whatever you specify
Yes, they do have to assume something and local TZ seems like the only
reasonable assumption.
CB> If you're not going have a DateTime object know its time zone, you
CB> should at least be able to specify a "from" and "to" timezone in
CB> ToTimeZone and MakeTimeZone.
I agree, providing "tzFrom" argument to these functions would be helpful.
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?
Thanks,
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.
Christopher Barker
> can you call
>
> Unfortunately you can't. We'd need to either change the time zone
> temporarily which is not really acceptable in MT programs
I agree.
> or never use strftime() for non-local TZ.
Wow! this is a MAJOR limitation of the system libs -- oh well.
> please do open a Trac ticket for it
Done: http://trac.wxwidgets.org/ticket/10445
I didn't set: Owned By, Milestone, or Version.
> I
> don't promise at all to work on this in the near future,
Thanks for your time so far.