Schwab - wrong transaction dates

K123

Some internet sleuthing turned up this contact info as well for Pehr Lawson, VP of Quicken Customer Care: [Removed - Personal Information]

I haven't emailed him yet, but he's next on the list.

veegee

I have written again, this time to multiple top executives. Mr. Dunn, Mr. Lawson and Mr. Villanueva.

Quicken Janean

Hi All, We have an update regarding this issue. Please take a look when you have a chance. Thanks!

https://community.quicken.com/discussion/7955108/ongoing-8-29-24-charles-schwab-downloading-transactions-using-yesterdays-date

veegee

I heard back from Mr. Dunn. Thank you, Mr. Dunn!
I am sure he would not mind me reposting his reply here since there is nothing sensitive in it.

Mr. Gopal:

I believe we have posted an update to the Community today on the status of this issue.

My understanding is that Schwab made a change to their transaction timestamps over the summer, and this caused the date issue.  We have tried to persuade them to reverse that change and have not succeeded.  At this point we are going to implement a workaround on our end.

It does seem like this has taken longer to resolve than it should have.  I apologize for that.

Eric

veegee

As I have mentioned before, from my own personal programming experience, it is best to store and transport date/time information in UTC time. So I can understand why Schwab did it this way. The UTC time should be translated to local time when displaying to the user. That is IMHO; I am not going to get into a debate on it.

Date+time is often stored as a 'single' number called 'Epoch time" - which is the number of seconds since 00:00:00 Thursday 01 January 1970, UTC. Thus Epoch time incorporates both date and time, and can be translated to local time for a given timezone. It is not even necessary to have separate date and time fields in the transported data.

K123

I also got a nice email from Mr. Dunn in response to the note I sent yesterday which was very similar to the one you posted above. A representative from the Office of the President called me today as well to follow up. I am confident now that the issue is getting the right level of attention. I was very pleased to see they posted an update on the forums with more substance so the community can see the status of the fix.

Stu

This is good news. Not to be a Cassandra but I hope any changes made by Quicken are made only to their back office systems and will not require an update to the client user version. Many of us are still living with R52.33 owing to significant errors introduced into the Asset Allocation reports and not fixed since then (October, 2023). The Asset Allocation report includes many closed positions and thus does not represent the true picture of a portfolio. It has also been the subject of a stream of comments for the past 13 months without a fix.
If the Schwab trade day error requires a fix to the client version of Quicken, we will have to choose which error to live with. It is no wonder the BBB rates Quicken an F for customer support.

Rick8

They would rather spend the money on Pony Commercials than fix the real problems! In over 20 years of using Quicken, their customer/tech support has only been able to fix any issues I have had 2 times. I have always had to find a work around or the true fix came from the Community. Pretty sad!

smutschler

Wow. The Schwab revision of using a 00:00 GMT/UTC time stamp (now explained by the Quicken team) foots right back to that data feed download image that @BIll44 shared with us months ago! As we suspected, the problem was due to a Schwab change all along!

Insofar as Schwab tried to pass the buck, shame on them. In any event, it is odd that they seem to have eliminated Time of Day from the transaction date stamp in their data feeds. While not as important as the Trade Date, the Trade Time has significance, for example, when auditing a Bond or Option pricing. It is virtually certain that Schwab keeps the Trade Time in their internal systems, so odd that they would not pass that raw data along in data feeds.

One question: Quicken states that they have long been standardized on converting dates to Pacific Time. If Quicken had standardized on "Eastern Time" instead, would their conversion of Schwab's date still give a "day earlier" result?

veegee

No fix in the latest update, but that is probably too much to expect.

Bill44

I reported a problem with transactions not being downloaded until later in the morning. That issue magically took care of itself. When your request transactions, you use the same date structure in a from and to date, as the dates that are being returned in the transactions. Why were they able to fix the request dates and not the dates returned? Just a little mor gas for the fire.

tivolo

Just downloaded transactions this afternoon and, much to my surprise, the dates are correct! Anyone else seeing a change?

Stu

Yep. Fixed.

Even better - does not require a client app upgrade, so I can stay on R52.33 until they fix the problem with the Asset Allocation report - now 13 months without a fix.

holthad

I also had good dates download this afternoon. Very happy to see this.

Quicken Janean

Hi All, this issue is resolved. Please let me know if you are still experiencing this issue. Thank you.

JPG

@Quicken Janean

Unlike other posters, when I downloaded my Schwab transactions from today (11/21), they were all erroneously dated with yesterday's date (11/20) and I had to manually correct them. I will try again with tomorrow's transactions, but I am wondering why mine would still be wrong when others are now correct. Please note that I am a former TD Ameritrade customer who was "migrated" over to Schwab in February of this year. Maybe that is making a difference.

veegee

Yes, downloaded this evening, and dates were correct. WOO-HOO!!!
I sent a note thanking the executives.

Now, to unlearn my correcting of the dates automatically without thinking…

veegee

@Quicken Janean I am guessing that you downloaded earlier in the day, and the problem was corrected later in the day. Some of us downloaded later in the day (like me). Correction probably happened at the intermediary aggregator (guessing) and did not require Quicken change.

wrozenwaser

Downloaded today's 11/22 txns from Schwab and they had the CORRECT date. Fingers crossed the issue stays fixed.

smutschler

I downloaded fresh dividend transactions in my Schwab accounts this morning and they had today's date! Hallelujah!

There is no doubt that the combined efforts of this community, when we really cranked up the outbound letters and calls, raised the sense of urgency of senior management at both Quicken and Schwab. I followed up with a Thank You note to both CEOs.

The Quicken community rocks!

JPG

https://community.quicken.com/discussion/comment/20462734#Comment_20462734

No, actually I downloaded my transactions after market close - as I usually do - and they came in with the wrong date. Today, again downloaded after market close and VOILA they correctly show today's date. So, hopefully, the problem is truly fixed.

JPG

@Quicken Janean

Update - yesterday I reported that downloaded transactions still arrived with the incorrect date. When I downloaded today's transactions, they processed into my Quicken file with the correct date. Hopefully, all is fixed. To paraphrase former President Gerald Ford, perhaps "our long Quicken nightmare has ended!"

veegee

@JPG , @Quicken Janean After the issue was fixed by Quicken/Intuit, you both experienced errors still in your download - this is because your download request did not result in a new data fetch from Schwab. Instead, you were served data that was downloaded earlier from the cache where the date data (from Schwab) was not interpreted correctly.

When you downloaded again after a few hours, the cache had timed out, data was fetched again from the Schwab servers, newly corrected interpretation of the data took place, and you received new and corrected data.

I have explained this caching behavior many times in this thread. Even though it is not directly tied to the date interpretation issue, it needs to be taken into account on all observations on investment transaction downloads. But, enough said on the subject from me. Except to say that: I do wish the cache timeout be reduced to an hour or less. But that is another topic.

veegee

Just to add a quick follow-up note, I have put in an enhancement request to make the caching behavior less painful for the users. See below.

https://community.quicken.com/discussion/7958036/update-cached-data-from-schwab-other-investment-fis-more-frequently-edited

[Edited - Updated Link]