Log of /contributions/modules/date/date_api_sql.inc
Parent Directory
| 
Revision Log
| 
Revision Graph
Revision
1.9.2.3.2.24
Fri Sep 5 11:03:56 2008 UTC
(14 months, 3 weeks ago)
by
karens
Branch:
DRUPAL-6--2
Changes since
1.9.2.3.2.23: +1 -1 lines
FILE REMOVED
Update to new Views2 API. Now requires latest versions of Views and CCK, and files have been re-arranged.
Revision
1.9.2.4 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Tue May 27 14:11:56 2008 UTC
(18 months ago)
by
karens
Branch:
DRUPAL-6--1
Changes since
1.9.2.3: +281 -2 lines
Diff to
previous 1.9.2.3
, to
branch point 1.9
, to
next main 1.16
Starting process of moving lots of similar date handling and navigation code out of Date and Calendar and into the Date API where we can use the same code everywhere. Adding a flexible date argument to the API that will work on any Views date field and take any ISO date argument. Adding an argument default option to set a missing date argument to the current date that will work on any date field. Adding a date back/next navigation attachment that works with the date argument and which can be attached to any view. Next step will be to go in and adapt the Calendar module to share this code instead of creating its own.
Revision
1.8 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Feb 17 14:01:39 2008 UTC
(21 months, 1 week ago)
by
karens
Branch:
MAIN
Changes since
1.7: +0 -0 lines
Diff to
previous 1.7
Simplify the API by assuming all date element values are handled in DATETIME format. The CCK Date module handles conversion of ISO and UNIX values to and from DATETIME values. This simplification of the core API should make it easier to get into core and makes the element handling easier to follow, plus I assume the first thing we'll do when a date API is in core is convert core timestamp fields to true DATETIME fields, so this would be the natural default.
Revision
1.7 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri Feb 15 13:23:53 2008 UTC
(21 months, 1 week ago)
by
karens
Branch:
MAIN
Changes since
1.6: +115 -72 lines
Diff to
previous 1.6
Remove database timezone handling by rolling back to previous version that used offsets instead. Based on problems noted in #218479 and #220663, we cannot count on database timezone handling to be available in MYSQL or work consistently with the timezone names that PHP uses in POSTGRES, so trying to do timezone conversions in the database is not going to work.
Synch with D5.2 version.
Revision
1.4.2.3 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Fri Feb 15 13:01:19 2008 UTC
(21 months, 1 week ago)
by
karens
Branch:
DRUPAL-5--2
CVS Tags:
DRUPAL-5--2-0-RC
Changes since
1.4.2.2: +115 -72 lines
Diff to
previous 1.4.2.2
, to
branch point 1.4
Remove database timezone handling by rolling back to previous version that used offsets instead. Based on problems noted in #218479 and #220663, we cannot count on database timezone handling to be available in MYSQL or work consistently with the timezone names that PHP uses in POSTGRES, so trying to do timezone conversions in the database is not going to work.
More commits are coming to re-apply patches made after this change.
Revision
1.5 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Feb 3 17:40:16 2008 UTC
(21 months, 3 weeks ago)
by
karens
Branch:
MAIN
Changes since
1.4: +72 -109 lines
Diff to
previous 1.4
Getting rid of offsets!! Alter query code to cast ISO and UNIX dates to native datetimes and do timezone conversion in the database. Much faster and more accurate.
This will mean this version of the code will not work for databases that are not able to do native timezone conversion, but even inexpensive shared hosts will probably have the MYSQL database timezone tables installed, and PostgreSQL has good timezone handling enabled by default.
The MYSQL timezone conversion code should be accurate, the PostgreSQL code looks right from the documentation but needs to be verified.
The offset fields can now be dropped from the Date fields since we only need the timezone name to do the conversion.
I probably missed some places that need to be adjusted for this change, but this should get most of the necessary fixes in place.
Revision
1.4.2.1 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sun Feb 3 17:39:58 2008 UTC
(21 months, 3 weeks ago)
by
karens
Branch:
DRUPAL-5--2
Changes since
1.4: +72 -109 lines
Diff to
previous 1.4
Getting rid of offsets!! Alter query code to cast ISO and UNIX dates to native datetimes and do timezone conversion in the database. Much faster and more accurate.
This will mean this version of the code will not work for databases that are not able to do native timezone conversion, but even inexpensive shared hosts will probably have the MYSQL database timezone tables installed, and PostgreSQL has good timezone handling enabled by default.
The MYSQL timezone conversion code should be accurate, the PostgreSQL code looks right from the documentation but needs to be verified.
The offset fields can now be dropped from the Date fields since we only need the timezone name to do the conversion.
I probably missed some places that need to be adjusted for this change, but this should get most of the necessary fixes in place.
Revision
1.3 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Mon Dec 17 22:53:00 2007 UTC
(23 months, 1 week ago)
by
karens
Branch:
MAIN
Changes since
1.2: +76 -3 lines
Diff to
previous 1.2
Build in ability to do native db timezone adjustments in queries, won't work until we have a native datetime field in the database.
Revision
1.1 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Sat Jul 28 21:51:29 2007 UTC
(2 years, 4 months ago)
by
karens
Branch:
MAIN
Very preliminary rewrite of Date API to become version 5.2. Not ready to be used yet! Still coming is rewrite of date and calendar module to use new API.
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
select a symbolic revision name using the selection box, or choose
'Use Text Field' and enter a numeric revision.
