Should we drop the timezone option from IS_DATE?

[Anthony]

First, the current implementation appears to be broken -- whether the value passed in is a datetime.date object or a string, the conversion process fails due to bugs. More generally, it's not clear how to convert a date to a different timezone, as it depends on the time of day. We could assume a time of midnight, but should it be midnight local or midnight UTC? Even if we settle that issue, we still have the problem that the timezone information is not stored in the database itself, so other tools that read the database may fail to make the proper transformation. Do we really need this option, or would it be better to use datetime fields when tracking timezones?

Anthony

[Massimo DiPierro]

yes. we should only deal with timezones in DATETIME, not DATE. There is no way the latter could work.

On Oct 25, 2015, at 12:15 PM, Anthony <abas...@gmail.com> wrote:

First, the current implementation appears to be broken -- whether the value passed in is a datetime.date object or a string, the conversion process fails due to bugs. More generally, it's not clear how to convert a date to a different timezone, as it depends on the time of day. We could assume a time of midnight, but should it be midnight local or midnight UTC? Even if we settle that issue, we still have the problem that the timezone information is not stored in the database itself, so other tools that read the database may fail to make the proper transformation. Do we really need this option, or would it be better to use datetime fields when tracking timezones?

Anthony

--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Anthony]

OK, I submitted an issue as a reminder.

Anthony

On Sunday, October 25, 2015 at 1:23:11 PM UTC-4, Massimo Di Pierro wrote:

yes. we should only deal with timezones in DATETIME, not DATE. There is no way the latter could work.

On Oct 25, 2015, at 12:15 PM, Anthony <abas...@gmail.com> wrote:

First, the current implementation appears to be broken -- whether the value passed in is a datetime.date object or a string, the conversion process fails due to bugs. More generally, it's not clear how to convert a date to a different timezone, as it depends on the time of day. We could assume a time of midnight, but should it be midnight local or midnight UTC? Even if we settle that issue, we still have the problem that the timezone information is not stored in the database itself, so other tools that read the database may fail to make the proper transformation. Do we really need this option, or would it be better to use datetime fields when tracking timezones?

Anthony

--
-- mail from:GoogleGroups "web2py-developers" mailing list

make speech: web2py-developers@googlegroups.com
unsubscribe: web2py-developers+unsubscribe@googlegroups.com

details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to web2py-developers+unsubscribe@googlegroups.com.