In plugging away at making the DateTime code lazier, something I've observed
is that time zones make everything more complicated. If DateTime didn't need
to worry about time zones everything would be a lot simpler.
Ok, duh. The second observation is that a DateTime object contains two
parallel sets of data. There's the datetime in UTC and the datetime in the
local time zone. This makes the code extra special complicated. It all has
to be kept in sync and it all has to be pre-calculated and a given object only
uses a fraction of it.
My thinking is this. Make DateTime::UTC which is a version of DateTime which
does not account for time zones. Make DateTime::Local which does. DateTime
now becomes a container for these two objects to which it delegates. This
untangles the logic.
DateTime can then only create which object it needs on demand. If you don't
give it a time zone, it only makes DateTime::UTC. It could even become a
DateTime::UTC object and avoid the overhead of delegating. If you give it a
time zone, it will create a DateTime::Local object and delegate to that. If
you make a change, say you add a day to it, it will apply the change to the
one that makes sense and invalidate the other object which will recalculate on
demand. Or maybe it will apply the change to both objects if that makes sense.
Its not clear yet how far DateTime::Local can get without DateTime::UTC, but
the other way sure can.
Thoughts?
--
I am somewhat preoccupied telling the laws of physics to shut up and sit down.
-- Vaarsuvius, "Order of the Stick"
http://www.giantitp.com/comics/oots0107.html
