[Zope-dev] DateTime.py

[Steve Alexander]

There's a problem with strftime() in DateTime.py.

Try this DTML method to see:

----
<dtml-var standard_html_header>
<dtml-let time1="_.DateTime('2000/07/23 BST')">
  Time: <dtml-var time1> <br>
  Time: <dtml-var time1 fmt=Date> <br>
  Time: <dtml-var time1 fmt="DayOfWeek"> <br>
  Bad Time: <dtml-var time1 fmt="%a, %d %B %Y %Z"> <br>
  Time: <dtml-var "time1.fCommonZ()"> <br>
</dtml-let>

<dtml-let time1="_.DateTime('2000/07/23 GMT')">
  Time: <dtml-var time1> <br>
  Time: <dtml-var time1 fmt=Date> <br>
  Time: <dtml-var time1 fmt="DayOfWeek"> <br>
  Time: <dtml-var time1 fmt="%a, %d %B %Y %Z"> <br>
  Time: <dtml-var "time1.fCommonZ()"> <br>
</dtml-let>

<dtml-var standard_html_footer>
----

Note that the time given in the line "Bad Time:" above is actually wrong
-- it reports itself to be in GMT, but gives the time as one hour
behind.

If you specify a date as YYYY/MM/DD, then the date that is stored is
(quite reasonably) midnight on that day, in your timezone.

This gets rendered back into days correctly for methods such as
DateTime.day(), as these methods directly ask the DateTime instance for
what it thinks the day is. The instance replies in the context of its
own timezone (as given in the constructor, or the local timezone if none
was given), and so it returns the expected result.

If you use the strftime() method, by using fmt="%d %H %Z" or whatever,
instead of asking the DateTime instance to do the formatting, the
formatting is delegated to the Python time module.

Unfortunately, at any particular time, the Python "time" module only
knows about two timezones: Your local one (with and without daylight
savings) and GMT.

Therefore, in any other timezones, Pythons time.strftime() cannot
correctly render the time.

This is particularly apparent in the current DateTime.py, because its
strftime method just interprets the internal representation of the time
as GMT, whatever.

We can fix this easily:

*** lib/python/DateTime/DateTime.py     Sun Jul 23 20:03:05 2000
--- lib/python/DateTime/DateTime.old.py Sun Jul 23 20:03:04 2000
***************
*** 1376,1382 ****
          return millis
  
      def strftime(self, format):
!         return strftime(format, gmtime(self.toZone('GMT').timeTime()))
  
      # General formats from previous DateTime
      def Date(self):
--- 1376,1382 ----
          return millis
  
      def strftime(self, format):
!         return strftime(format, gmtime(self.timeTime()))
  
      # General formats from previous DateTime
      def Date(self):


Now, at least, the time will be reported correctly, although not really
usefully if you want to have the time formatted in the timezone given to
the DateTime instance.

Also, this patch will cause formatting calls to create a new DateTime
instance if the instance you want to format is not in timezone GMT+0. 

The only general solution that I can see is to replicate the formatting
algorithms of the time module in DateTime.py, but written so that they
take account of timezones.


There is another issue:

When I call _.DateTime('2000-07-23'), what do I mean? 

The current implementation of DateTime interprets that as "midnight (the
earliest possible time) on 2000-07-23, interpreted in the local
timezone".

However, if I'm being naive, I might think that I'm refering to a Day,
and that the Day should be the same day no matter what timezone I put it
into.

In that case, the DateTime module needs rewriting to have a sense of
precision built into it: If I specify a time to the day, I get the
latter behaviour. If I specify the time more precisely, I get the
current behaviour.

Another approach would be to make _.DateTime('2000-07-23') mean Midday,
GMT rather than Midnight, local time. That would give the latter
behaviour for most timezones at most times; the exceptions being places
near the international date line that are in daylight savings time.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net