Bugs item #1699489, was opened at 2007-04-12 21:32
Message generated for change (Comment added) made by mgeisler
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Parsing
Group: None
>Status: Closed
>Resolution: Fixed
>Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin Geisler (mgeisler)
Summary: Incorrect UNIX/Julian conversion

Initial Comment:
In the class PelEntryTime, the conversion taking place between the Julian 
calendar and a UNIX timestamp is not always correct.

For example, should you get the value of the time as a UNIX timestamp (hereby 
referred to as t) and add a number of seconds to it, and then set the value to 
the new value -> setValue(t+x), then the Julian conversion can be incorrect if 
the addition of X makes the time roll over into the next day (i.e. from 11:59pm 
on 01/01/2007 to 12:01am on 01/02/2007). The time will be correct, but the day 
will be one day behind (giving you 01/01/2007 12:01am).


>Comment By: Martin Geisler (mgeisler)
Date: 2007-04-24 20:56

Logged In: YES 
Originator: NO

Thanks for reporting this! It turned out to be a timezone-problem. I used
the unixtojd() function which interprets the timestamp according to the
local timezone.

Simply subtracting the timezone offset is almost enough to fix this, but
not quite: a timestamp such 600 meaning Jan 1st 1970 00:10:00 becomes -3000
in my normal timezone. But unixtojd() cannot handle negative timestamps!

It turned out to be easier to use the PHP implementation jdtounix().


You can respond by visiting: 

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
PEL-devel mailing list

Reply via email to