bugphpGroupWare - Bugs: bug #10279, calendar can't handle Dates before...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #10279: calendar can't handle Dates before 1970

Submitter:  Matthias Leonhardt <mleonhardt>
Submitted:  Mon 06 Sep 2004 12:16:37 PM UTC
   
 
Category:  calendar Item Group:  0.9.16.003
Severity:  3 - Normal Priority:  5 - Normal
Status:  Wont Fix Privacy:  Public
Assigned to:  skwashd Open/Closed:  Closed
Component Version:  SVN Operating System:  GNU/Linux - SuSE
Reproducibility:  None Planned Release:  0.9.18.000
Fixed Release: 

Jump to the original submission

Sun 04 Dec 2005 09:46:37 AM UTC, comment #6: 

Closing

As app maintainer I have no plans to fix this as I don't consider it a bug within phpgw.  The patch mentioned by the OP was never provided.

WONTFIX

Dave Hall <skwashd>
Group administrator
Thu 09 Sep 2004 09:21:00 PM UTC, comment #5: 

It isn't as straight forward as that.  We need to support php on multiple platforms, and windoze does not support pre1970 date timestamps.  See: http://www.php.net/date

"Note:  The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer). On Windows this range is limited from 01-01-1970 to 19-01-2038."

You could look at http://phplens.com/phpeverywhere/adodb_date_library, but it would also require schema changed and a major find and replace within the code.

You are free to do what you want with pbgw but how phpgw deals with the problem, is something I will think about.

Dave Hall <skwashd>
Group administrator
Thu 09 Sep 2004 09:08:49 AM UTC, comment #4: 

So we have to make a patch for our pbgroupware-branch.
Are all of these changes really neccessary? Perhapps it helps if I write a php-function which is able to use negative timestamps so we get the mktime function working with it.

Cheers,
Matthias

Matthias Leonhardt <mleonhardt>
Thu 09 Sep 2004 09:06:00 AM UTC, comment #3: 

Did the suggestion below solve the problem?

Matthias Leonhardt <mleonhardt>
Thu 09 Sep 2004 08:10:56 AM UTC, comment #2: 

Before you go and get all irrationaly about this problem again, as you did in bug #10331, stop and relax for a minute.

Here is the project policy:

  • No schema changes in stable
  • No new features in stable
  • Bug fixes in 16 only


Sync is not a supported 16 module, so any problems it has working with 16 is not a bug in the 16 branch.

A fix for this would involve major changes for the calendar app:

  • db schema change to support doubles instead of ints for dates


  • change all of the logic to use julian dates


  • logic to support storing the time component of the event as a decimal (1 second = 0.000000193 julian days)


  • conversion scripts to transfer all of the data to the new schema.


  • some testing would also be useful


This will not be fixed quickly.  I have little interest atm spending the huge amounts of time required to fix this.  The calendar app needs some serious attention, fixing this can wait until I have time to fix most of the problems at once.

Dave Hall <skwashd>
Group administrator
Tue 07 Sep 2004 09:33:52 PM UTC, comment #1: 

won't be fixed in 16.  Also birthdays are recurring events, which should not have been entered pre1970.

This is more of a problem in the addressbook, which is covered by a seperate bug report.

Dave Hall <skwashd>
Group administrator
Mon 06 Sep 2004 12:16:37 PM UTC, original submission:  

while syncing we use
$this->bo_iCal->import($data_lines, true, $timestamp);
to get new calendar-entries.
But if we have an entry (i.e. birthday) before 1970 the calendar can't handle this. php produces warnings: localtime doesn' support negative values.
perhapps you know a way to handle this.
kind regards,
Matthias

Matthias Leonhardt <mleonhardt>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 4 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-12-04 skwashd StatusNone Wont Fix
    Open/ClosedOpen Closed
2004-09-07 skwashd Planned Release0.9.16.011+ 0.9.18.000
2004-09-06 mleonhardt Carbon-Copy- Added cboettger

Back to the top

Powered by Savane 3.13-caa5.
Corresponding source code