Schwab - wrong transaction dates

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.

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.

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.

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?

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.

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.

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…

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

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 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.