This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Fergus.Noble
Recipients Fergus.Noble, belopolsky, benjamin.peterson, jamesh, mark.dickinson, vstinner
Date 2012-11-04.07:11:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
GPS time doesn't include leap seconds so I think datetime is a good representation. If datetime doesn't know about leap seconds then there would still be some issues with finding the timedelta between a GPS time and a UTC time straddling a leap second but I guess a similar issue also exists with two UTC times.

For my application all the times I am dealing with are in a short period and will have the same UTC offset so its a little easier, I can probably avoid most of these issues.

However, wouldn't it be possible to implement the general case with a non-constant utcoffset function (and new fromutc implementation) in the tzinfo class? Of course there is no way to properly handle UTC times more than 6 months or so in the future...
Date User Action Args
2012-11-04 07:11:28Fergus.Noblesetrecipients: + Fergus.Noble, jamesh, mark.dickinson, belopolsky, vstinner, benjamin.peterson
2012-11-04 07:11:28Fergus.Noblesetmessageid: <>
2012-11-04 07:11:28Fergus.Noblelinkissue5288 messages
2012-11-04 07:11:28Fergus.Noblecreate