But thats exactly what you get when you ask questions that require shifting, specific contextual knowledge. The model weights, by their nature, cannot encode that information.

At best, you can only try to layer in contextual info like this as metadata during inference, akin to how other prompting layers exist.

Even then, what up-to-date information should present for every round-trip is a matter of opinion and use-case.

> The model weights, by their nature, cannot encode that information.

This is mostly irrelevant no? A binary digit by definition cannot encode more than 2 dates; so therefore we devise a more elaborate system (of using multiple digits).

This is very similar to NYT's lawsuit against OpenAI where in addition to other claims, they claimed OpenAI maintainted a DB of NYT articles that they would directly grab from for a response. It's seems very feasible to maintain a DB or system of looking up real-time values like dates / weather.

> Three months later in April when this tagged data is used to train the next iteration, the AI can successfully learn that today's date is actually January 29th.

Such an ingenious attack, surely none of these companies ever considered it.

the date is in the "system prompt", so the cron job that updates the prompts to the current date may be in a different time zone than you. 7f5dbb71f54322f271c4d3fc3aaa4d3282a1af5541d82b2cbc5aa10c1420b6bc

why can't they feed in user data like time zone and locale?

They're not actually processing the entire system prompt (which is rather long) on every query, but continuing from a model state saved after processing the system prompt once.

That makes it a bit harder, but still, spitting out the wrong date just seems like a plain old time-zone bug.