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.