[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 )
