[Zope] Re: DateTime().Time() gets Insufficient Privileges error, why?
Nevermind. I later found that I could not call HTTPConnection from my python script in Zope and ended up going straight to running it in python 2.3. Jamie On 12/28/05, Jamie O'Keefe [EMAIL PROTECTED] wrote: I am trying to get the latest time in a Python Script. I declare: from DateTime.DateTime import DateTime But when I run: t = DateTime().latestTime() or t = DateTime().Time() I always get an Insufficient Privileges error. I have combed through the archives and the web and as far as I can tell this should work. What am I doing wrong? Thanks! Jamie ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime().Time() gets Insufficient Privileges error, why?
Thanks Andreas and Jens for the helpful tip. Jamie ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime mess
Chris Withers wrote: Just a note: I don't think mixing in persistance is needed. Hmm... how so? I've always thought it quite nice that when, for example, you store the modification time of an object in a DateTime, you can safely update it without worrying about the whole object having to be repickled when you change it... Except that this doesn't work that way today. DateTime object don't subclass persistent. What you're proposing doesn't make much sense to me anyway, if you want to change the modification time of an object then it means something else changed. No need to isolate the modification time change in its own persistent subobject. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime mess
[ Florent Guillaume wrote:] Jürgen Herrmann wrote: recently i came up here with the intention to fix DateTime#strftime(). while trying this, i had to dig deeper and deeper into the implementation of DateTime and especially the timezone and daylight saving stuff. to be honest, it's completely hacked together :( DateTimeZone.py has one BIG dictionary in it, not a single line of comments. values of this dict are nested lists, among other hackish things (list like usage of a string, with \000 as separator). the methods that use this dict also have no comments/docstrings at all. obviously the guy(s) that originally wrote this, is/are hiding (i know why :) so, there's nobody to ask either... sorry guys, i won't be able to completely fix this for now. i found a way to monkey patch zope to make it work for my case (2 timezones only). my plan is to completely reimplement DateTime, based on python's datetime in my own freetime (maybe around xmas this year) and give it back to the community. once again sry, if i raised expectations on the fix of strftime. Yes replacing DateTime is a laudable but difficult goal. One thing that could be done meanwhile is just refactor the unit test to be a base class that could then be used to test DateTime or to test another potential implementation. That would go a long way to help actually write a new implementation. Florent hi florent! actually that's the best thing to do! this way the implementer knows what to do exactly :) but be aware that some tests got modified to pass with current (broken) behaviour! one more question (to the public!): do we REALLY need dates 1900 / 2036 ? using unix timestamps for storage and as the base for all conversions would make things a lot easier! regards, juergen herrmann ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime mess
On 11/22/05, Jürgen Herrmann [EMAIL PROTECTED] wrote: do we REALLY need dates 1900 / 2036 ? Yes. using unix timestamps for storage and as the base for all conversions would make things a lot easier! datetimes are picklable, so if you are going to change how they are stored (which may not be a good idea for backwards compatible reasons), you should use that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime mess
[ Lennart Regebro wrote:] On 11/22/05, Jürgen Herrmann [EMAIL PROTECTED] wrote: do we REALLY need dates 1900 / 2036 ? Yes. using unix timestamps for storage and as the base for all conversions would make things a lot easier! datetimes are picklable, so if you are going to change how they are stored (which may not be a good idea for backwards compatible reasons), you should use that. i'll surely change the storage format, when rewriting it! storing year, month, day, hour, minute, second, a unix timestamp and tzinfo is plain odd! so using a datetime instance for storage indeed seems the most obvious thing if we need dates 1900 / 2036. regards, juergen herrmann ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime mess
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jürgen Herrmann wrote: [ Florent Guillaume wrote:] Jürgen Herrmann wrote: recently i came up here with the intention to fix DateTime#strftime(). while trying this, i had to dig deeper and deeper into the implementation of DateTime and especially the timezone and daylight saving stuff. to be honest, it's completely hacked together :( DateTimeZone.py has one BIG dictionary in it, not a single line of comments. values of this dict are nested lists, among other hackish things (list like usage of a string, with \000 as separator). the methods that use this dict also have no comments/docstrings at all. obviously the guy(s) that originally wrote this, is/are hiding (i know why :) so, there's nobody to ask either... sorry guys, i won't be able to completely fix this for now. i found a way to monkey patch zope to make it work for my case (2 timezones only). my plan is to completely reimplement DateTime, based on python's datetime in my own freetime (maybe around xmas this year) and give it back to the community. once again sry, if i raised expectations on the fix of strftime. Yes replacing DateTime is a laudable but difficult goal. One thing that could be done meanwhile is just refactor the unit test to be a base class that could then be used to test DateTime or to test another potential implementation. That would go a long way to help actually write a new implementation. Florent hi florent! actually that's the best thing to do! this way the implementer knows what to do exactly :) but be aware that some tests got modified to pass with current (broken) behaviour! one more question (to the public!): do we REALLY need dates 1900 / 2036 ? using unix timestamps for storage and as the base for all conversions would make things a lot easier! Yes, we do need them. The Unix timestamp epoch starts at 1970, BTW. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDgwz0+gerLs4ltQ4RAt95AJ9yGr7egzS6Fb6/Tlq3d196CccA1gCgkZeO Zs+XUWMJ9QhG8G4XRTOUF0k= =GaZ6 -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime mess
On 11/22/05, Jürgen Herrmann [EMAIL PROTECTED] wrote: i'll surely change the storage format, when rewriting it! So you plan on having some version marker, or so, which tells which storage format is used? //Curious. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime mess
[ Lennart Regebro wrote:] On 11/22/05, Jürgen Herrmann [EMAIL PROTECTED] wrote: i'll surely change the storage format, when rewriting it! So you plan on having some version marker, or so, which tells which storage format is used? //Curious. basicall i thought about having a dateime instance as storage in the new implementation and test for it's existance on DateTime instances. something like that: dt = getattr(self, '_datetime', None) if dt is not None: #new, everything ok else: #migrate! rfc! regards, juergen herrmann ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime mess
At Tuesday 22/11/2005 05:50, Jürgen Herrmann wrote: one more question (to the public!): do we REALLY need dates 1900 / 2036 ? using unix timestamps for storage and as the base for all conversions would make things a lot easier! Sure. What about birthdays of aged people? Long running forecasts? Gabriel Genellina Softlab SRL ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime mess
On Nov 22, 2005, at 11:27 AM, Gabriel Genellina wrote: At Tuesday 22/11/2005 05:50, Jürgen Herrmann wrote: one more question (to the public!): do we REALLY need dates 1900 / 2036 ? using unix timestamps for storage and as the base for all conversions would make things a lot easier! Sure. What about birthdays of aged people? Long running forecasts? The first time I read this, I thought it said long-running people, which would be funnier. ;-) ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime mess
Jürgen Herrmann wrote: recently i came up here with the intention to fix DateTime#strftime(). while trying this, i had to dig deeper and deeper into the implementation of DateTime and especially the timezone and daylight saving stuff. to be honest, it's completely hacked together :( DateTimeZone.py has one BIG dictionary in it, not a single line of comments. values of this dict are nested lists, among other hackish things (list like usage of a string, with \000 as separator). the methods that use this dict also have no comments/docstrings at all. obviously the guy(s) that originally wrote this, is/are hiding (i know why :) so, there's nobody to ask either... sorry guys, i won't be able to completely fix this for now. i found a way to monkey patch zope to make it work for my case (2 timezones only). my plan is to completely reimplement DateTime, based on python's datetime in my own freetime (maybe around xmas this year) and give it back to the community. once again sry, if i raised expectations on the fix of strftime. Yes replacing DateTime is a laudable but difficult goal. One thing that could be done meanwhile is just refactor the unit test to be a base class that could then be used to test DateTime or to test another potential implementation. That would go a long way to help actually write a new implementation. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime strftime problem
zope 2.7.8's DateTime::strftime() looks like this:
def strftime(self, format):
# Format the date/time using the *local timezone representation*.
return strftime(format, safelocaltime(self.timeTime()))
it seems that my assumption about strftime's behaviour was incorrect.
why do we have time zones at all, if strftime always uses the machine's
local time zone?
would this be better off in a new method, similar to strftime but
respecting the DateTime's current time zone? (that's what i need)
submitting a patch with my implementation is likely to be refused
because it changes long standing behaviour...
on the other hand, if DateTime's strftime should behave as similar
as possible to datetime's strftime, it should respect the timezone
information attached to it.
honestly i don't know what to do... i can just make this a monkeypatch
and only use it myself, but that just didn't feel like the right thing
to do :)
regards, juergen herrmann
[ Florent Guillaume wrote:]
The DateTime implementation in Zope is notoriously undertested and
underspecified when it comes to time zones. Until recently strftime was
quite buggy too, and as you saw it has been recoded in terms of the python
datetime implementation now that it exists. It's very possible that a bug
was introduced at that point, it would be useful to check with Zope 2.7's
DateTime. Or the bug has always been there.
It think it's a good thing if DateTime can behave more regularly, which
means be more in line with python's datetime, in corner cases.
Please submit a patch to the collector. It probably will be included in
2.9
but not 2.8 which is strictly in maintenance mode, unless you convince us
that it's very unlikely that code would change behavior as a result.
Florent
Jürgen Herrmann wrote:
[ Jürgen Herrmann wrote:]
i looked at the source of DateTime::strftime(), surpirse, surprise :)
strftime uses python's datetime class and it's strftime method!
but no care is taken at this time for timezone information, so i
decided to code a tzinfo subclass for datetime that can represent
fixed offset from gmt (no dst) and hand one such instance to
datetime.fromtimestamp(). seems like this code is working correctly now.
i'll run it against some tests tomorrow and report back on the results.
regards, juergen herrmann
if i run the DateTime testsuite against my patched version:
==
ERROR: Checks strftime in dates = 1900 or = 2038
--
Traceback (most recent call last):
File /usr/lib/python2.4/unittest.py, line 260, in run
testMethod()
File /home/bliss/zope/lib/python/DateTime/tests/testDateTime.py,
line
366, in testStrftimeFarDates
self.assertEqual(dt.strftime('%d/%m/%Y'), '30/01/1900')
File /home/bliss/zope/lib/python/DateTime/DateTime.py, line 1542, in
strftime
ds = datetime.fromtimestamp(self._t+offsetsecs,
tzi).strftime(format)
ValueError: timestamp out of range for platform time_t
==
ERROR: Checks time zone in dates = 1900 or = 2038
--
Traceback (most recent call last):
File /usr/lib/python2.4/unittest.py, line 260, in run
testMethod()
File /home/bliss/zope/lib/python/DateTime/tests/testDateTime.py,
line
374, in testZoneInFarDates
self.assertEqual(dt1.strftime('%d/%m/%Y %H:%M'),
dt2.strftime('%d/%m/%Y %H:%M'))
File /home/bliss/zope/lib/python/DateTime/DateTime.py, line 1542, in
strftime
ds = datetime.fromtimestamp(self._t+offsetsecs,
tzi).strftime(format)
ValueError: timestamp out of range for platform time_t
==
FAIL: strftime timezone testing
--
Traceback (most recent call last):
File /usr/lib/python2.4/unittest.py, line 260, in run
testMethod()
File /home/bliss/zope/lib/python/DateTime/tests/testDateTime.py,
line
361, in testStrftimeTZhandling
self.assertEqual(dt_string, dt_localstring)
File /usr/lib/python2.4/unittest.py, line 333, in failUnlessEqual
raise self.failureException, \
AssertionError: '2003-11-19 17:32 -0215' != '2003-11-19 21:47 GMT+0100'
--
Ran 32 tests in 13.056s
th first two are obviously side effects from using a timestamp for
the instantiation of my datetime object, could be fixed, not the focus
for now.
the third one brings me back to my initial question:
what is this code snippet supposed to return?
d = DateTime('2005/04/03 02:01 UTC')
d.toZone('GMT+1').strftime('%Y/%m/%d %H:%M %Z')
'2005/04/03 03:01 GMT+0100'
is this correct?
if so, the i would tend to say, the testcase was written to pass with
wrong strftime() behaviour. (*duck*)
Re: [Zope] Re: DateTime strftime problem
Jürgen Herrmann wrote at 2005-11-9 13:38 +0100: zope 2.7.8's DateTime::strftime() looks like this: def strftime(self, format): # Format the date/time using the *local timezone representation*. return strftime(format, safelocaltime(self.timeTime())) it seems that my assumption about strftime's behaviour was incorrect. why do we have time zones at all, if strftime always uses the machine's local time zone? Zope's strftime is simply broken. Forget about it. It should be simple to implement your own version in Python (and I think someone already did). Once you did, donate the implementation to Zope -- Dieter ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime strftime problem
[ Dieter Maurer wrote:] Jürgen Herrmann wrote at 2005-11-9 13:38 +0100: zope 2.7.8's DateTime::strftime() looks like this: def strftime(self, format): # Format the date/time using the *local timezone representation*. return strftime(format, safelocaltime(self.timeTime())) it seems that my assumption about strftime's behaviour was incorrect. why do we have time zones at all, if strftime always uses the machine's local time zone? Zope's strftime is simply broken. Forget about it. It should be simple to implement your own version in Python (and I think someone already did). Once you did, donate the implementation to Zope -- Dieter ok, i guess i can fix strftime. will take some time to change the tests and add some comments. i'd like to report with the patch here first and get some comments, to avoid don't dos... already came across another python bug in strptime, that reports a format error, if %Z (timezone *omg*) is in the format string and you give it value different to UTC... this IS getting interesting :) thanks for all your help... regards, juergen ___ XLhost.de - eXperts in Linux hosting Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: datetime bug
Thanks Lupa.
I have tracked it down and created a patch which fixes the problem in
general. Seems the ISO 8601 implementation had some warts. We are
testing the patch now. When I am sure it's OK I'll submit it to the
Collector with an URGENT tag. I'll also send you a copy.
I suspect that the daylight savings time behavior is unrelated to this
problem and is likely to be a bad entry in a table.
Thanks for you helpful response. BTW if you want an alpha copy of the
patch, let me know and I'll send it to you. The more testing the better.
The patched version has the following semantics
dates and times with no timezone tag resolve to the
timezone of the host machine (Zope standard behavior)
dates and times with a trailing Z are guaranteed to be
GMT
dates and times with a trailing offset have the offset
as their time zone.
It is illegal to combine a 'Z' and an offset. (Hacked in
the code for 2.7 beta)
I think this matches the spec at
http://www.w3.org/TR/NOTE-datetime
On Sun, 12 Jun 2005, +lupa+ wrote:
Hi Dennis,
I'm responding directly to you as I'm not on the zope list. I see the
same error on Zope 2.7.6 and with 2.3.5 python, not 2.4.x. I've narrowed
the behavior down a bit more and it seems that
dd = '%d-%02d-%02d' % (y,m,d,)
D = DateTime(dd)
converts to local time, while
ee = '%d/%d/%d' % (m, d, y)
E = DateTime(ee)
converts to Mean time. I'm not absolutely sure of that, but in a quick
look, I can see that the difference between D and E changes from -5 hours
to -3 when Daylight Savings Time change comes around... which seems a bit
weird in itself. I wrote and maintain CalendarX for Plone, so this
behavior concerns me greatly and I'll be looking into it more very soon.
+lupa+
Lupa Zurven, CalendarX.org
At 12:00 PM 6/12/2005 -0400, you wrote:
From: Dennis Allison [EMAIL PROTECTED]
Precedence: list
Subject: [Zope] Datetime bug in Zope-2.7.6?
Date: Sat, 11 Jun 2005 16:54:03 -0700 (PDT)
To: zope@zope.org
Message-ID: [EMAIL PROTECTED]
Content-Type: TEXT/PLAIN; charset=US-ASCII
MIME-Version: 1.0
Message: 5
Zope 2.7.6
Python 2.4.1 (and yes, I know I am jumping the gun a bit)
The problem appears to be in the parse component --
Consider a test script:
for y in range(1995,2005):
for d in (1, 3, 13, 25,):
for m in (1,4,5,6,):
dd = '%d-%02d-%02d' % (y,m,d,)
ee = '%d/%d/%d' % (m, d, y)
D = DateTime(dd)
E = DateTime(ee)
print dd, D.strftime('%Y-%m-%d')
print ee, E.strftime('%Y-%m-%d')
return printed
In all cases, each of the dates shoudl be the same. As can be seen,
for dates sourced from a string of the form
1995-04-25
the resulatant date is off by one day
1995-04-24
The problem is not seen with Zope 2.6.4 running with
Python 2.3.5.
A quick diff shows tht there are many changes between 2.6 and 2.7.
Anyone else seen this problem?
Partial Results:
1995-04-25 1995-04-24
4/25/1995 1995-04-25
1995-05-25 1995-05-24
5/25/1995 1995-05-25
1995-06-25 1995-06-24
6/25/1995 1995-06-25
--
Dennis Allison * Computer Systems Laboratory * Gates 227
* Stanford University * Stanford CA 94305
* (650) 723-9213 * (650) 723-0033 fax
* [EMAIL PROTECTED]
* [EMAIL PROTECTED]
--
Dennis Allison * Computer Systems Laboratory * Gates 227
* Stanford University * Stanford CA 94305
* (650) 723-9213 * (650) 723-0033 fax
* [EMAIL PROTECTED]
* [EMAIL PROTECTED]
___
Zope maillist - Zope@zope.org
http://mail.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime(), locale, summertime etc.
On Thu, Apr 07, 2005 at 11:22:39AM -0400, Paul Winkler wrote: Maybe this is relevant: http://www.zope.org/Collectors/CMF/325 ... crap, I never merged the fix. OK, now this is merged to the trunk and CMF-1_5-branch. -- Paul Winkler http://www.slinkp.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime(), locale, summertime etc.
Max M wrote: I have a product where I convert some external datetimes to zope DateTime() objects. I save them as UTC as zopes DateTime does by default. But when these are rendered, the time is offset by two hours. Ok. I was unclear here. I convert from datetime objects (python) to DateTime (zope) objects. The datetime objects are in UTC format. So are the DateTime objects. On an external system I enter a time of 11:00. The external system then saves the value as 9:00 UTC, which is correct. Taking summertime and time zone offset into account. When I convert to DateTime objects, they are saved as 9:00 Universal. So that is correct too. The DateTime objects are then displayed in Zope/Plone in UTC time. I would expect Zope to represent them in the systems locale 'danish' and display them as 11:00 I have set the locale danish directive in my zope.conf, but that doens't change anything. Does anybody have an idea as to what to try out next? -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime(), locale, summertime etc.
Max M wrote: When I convert to DateTime objects, they are saved as 9:00 Universal. So that is correct too. Ok. Turned out that I have misunderstood zopes DateTime(). It saves in UTC, but it still needs a timezone. So converting datetime objects to the local timezone and then converting to DateTime objects also as local timezone did the trick. hmmm -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime(), locale, summertime etc.
On Thu, Apr 07, 2005 at 02:44:38PM +0200, Max M wrote: Max M wrote: When I convert to DateTime objects, they are saved as 9:00 Universal. So that is correct too. Ok. Turned out that I have misunderstood zopes DateTime(). It saves in UTC, but it still needs a timezone. So converting datetime objects to the local timezone and then converting to DateTime objects also as local timezone did the trick. hmmm Maybe this is relevant: http://www.zope.org/Collectors/CMF/325 ... crap, I never merged the fix. I should really make it a habit to read the CMF issues nag mail :-0 -- Paul Winkler http://www.slinkp.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime
Jerome Alet wrote: On Fri, 10 Nov 2000, Chris Withers wrote: mxDateTime is _not_ the DateTime in Zope. If only it was It's voting season, so I vote +10 for this one. bye, I'll second that +10 kapil ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: DateTime
These aren't really hosting related so I'm moving this to the [EMAIL PROTECTED] list... Thiebaut CHAMPENIER wrote: The official home page for this module is http://starship.python.net/~lemburg/mxDateTime.html (not responding rigth now) IIRC, starship is down 'cos the Python team are moving to DC. mxDateTime is _not_ the DateTime in Zope. If only it was BTW, DateTime is a Python module, it is not specific to Zope. Unless I'm mistaken, the one in Zope is specific to Zope ;-) The solution will look something like that: dtml-var expr="_.DateTime(date_posted)" You may want soem fmt= in there, check the Zope Quick Reference... cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: DateTime
On Fri, 10 Nov 2000, Chris Withers wrote: mxDateTime is _not_ the DateTime in Zope. If only it was It's voting season, so I vote +10 for this one. bye, Jerome ALET - [EMAIL PROTECTED] - http://cortex.unice.fr/~jerome Fac de Medecine de Nicehttp://wwwmed.unice.fr Tel: (+33) 4 93 37 76 30 Fax: (+33) 4 93 53 15 15 28 Avenue de Valombrose - 06107 NICE Cedex 2 - FRANCE ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
