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
[ 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
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
[ 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
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
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.
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
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
[ 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
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
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
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
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
13 matches
Mail list logo
