I'm tempted to handle this in a different way altogether. You're the first to report it, but here we are. Every "fix" for one location has the potential to "disturb" someone in a different location. I'm hesitant, only because I didn't like globally changing timestamps to begin with. In all, it sounds like your logic of simply forcing any date later than "today" be equal to "today" isn't a bad approach. You have the opposite issue, in that the server is sending the a date/time combo that *would* translate correctly in the west. They recorded the time as 000000 for day x, but then this would interpret as day x-1 on the west coast. The "starter" for this issue was that Fidelity was sending quotes for day x, but it was recording for day (x-1).
Looking back, it appears some providers implement their time logic differently. Phil: I thought on this some more, and reviewed the reasons/logic used when implementing the date/time "scrubber" routine. > datetime = datetime + '120000' Reply Delete > #and time (assuming this happens thanks to timezone mismatch between #If nulltime is given with tomorrow's date, replace with current date > today = time.strftime("%Y%m%d%H%M%S", time.localtime(now)) > tomorrow = time.strftime("%Y%m%d", time.localtime(now + 86400)) Here are the diffs, which hopefully aren't too trashed by the commenting system:
#Microsoft money 2005 us code
I also added debug code to copy the original OFX file to a. If I see a date field with tomorrow's date, as YYYYMMDD, I replace it with the current date and time.
#Microsoft money 2005 us update
When that is tomorrow from the client timezone, you'll get a price update from the future and hit the problem in the Portfolio Manager and Account Summaries.Īnyway, I've made a fix for this in scrubber.py. This current date is for the server, which appears to be in Eastern time. The problem is Schwab sends a YYYYMMDD datetime for the current date, without a time, in the DTSERVER and DTASOF fields, and in DTPRICEASOF fields for unpriced securities (e.g. Schwab doesn't send any TZ offsets in their datetimes. Robert, thanks for the change, but it doesn't fix the Schwab issue. Note, however, that the html output may change by "time of day". If anyone has time to hack out a reliable html parse logic for the Google Finance site (e.g., ), then I could implement into the scripts pretty quick. I haven't given up, but it hasn't been a priority either. It was going to require more time than I had. There were inconsistencies there too, so I paused. I then moved to scoping out a screen parser for the Google GUI interfaces, as they do appear to support CA FUND quotes. Worse, their XML output was inconsistent, providing timestamps in varying formats depending on whether exchanges were open or closed (maybe more flags than that). An unfortunate oversight on my part up front, or something changed while I was writing the parser. I found out the XML interface didn't actually support CA funds, only STOCKs and ETFs. As they appeared to support CA funds, I wrote a parser for it. When I first looked at Google finance, I found an XML interface to their quote engine.