Holiday windows that change what a Chinese warehouse can do

What the public record fixes, and what it leaves open

Almost everything a buyer can verify about a chinese holiday warehouse closure comes from one document: the State Council arrangement notice, published in the preceding autumn, which sets the non-working days and the weekend swaps around them for the year ahead. That notice is a calendar rather than a service level. It fixes which days are non-working. It does not fix how long anything takes once work resumes, and no warehouse publishes that second number. Two buyers reading the same notice can therefore agree completely about the dates and still disagree about what those dates will do to a parcel, and only one of those two positions is checkable afterwards.

So this page keeps two columns apart. The window itself is public regulation, and it can be written down and checked against the notice on the day it is reissued. The consequence for one parcel is not published anywhere, and the honest entry against it is a question put to the agent with the reply kept in writing. A written answer also survives a change of staff, which a remembered phone call does not.

The table below is the whole of the public record as it affects an order: five windows that recur every year, what each notice fixes, and what stays a decision made by a seller or an agent rather than by a calendar.

What changes inside a warehouse while a window is running

A warehouse cannot intake what has not arrived, and a seller who dispatches on the last working day before a block hands the parcel to a domestic network that may not produce another scan until the block ends. Nothing is lost in that gap. The parcel simply generates no new state for you to read, which is why a tracking page that freezes during a window is not evidence of a problem. The domestic leg before the warehouse is where that gap is widest, because a seller can hand a parcel to a courier on the last working day and still be entirely truthful about having dispatched it.

Requests behave differently from parcels. A [merge and pack](/steps/merge-parcel/) request submitted during a window is normally queued rather than refused, but a queue is not progress, and the parcel is not sealed until somebody works it. That distinction matters because the address on file is read only when the parcel is actually built.

• Intake stops for anything still with a seller, and the matching row in your own log stays open rather than closing.
• A merge request submitted during a window waits, and nothing about it becomes final until it is worked.
• The storage clock is an agent-side rule, so whether it pauses over a public holiday is a written answer rather than a published one.
• Dispatch promises printed in a listing are written for normal weeks and do not survive a public holiday intact.

Why no congestion figure appears on this page

A congestion figure would be a forecast wearing the clothes of data. The queue after a block depends on how many sellers closed, how many parcels arrived in the same few days, how many staff returned on the first working day, and which carriers added collections. None of that is published by anyone, and a number invented here would be repeated by readers as though it were a finding.

What is knowable is narrower and still useful. The window dates come from the notice, the state of each parcel comes from your own account, and the storage answer comes from your agent in writing. Everything else is somebody’s memory of a bad week, and memories of bad weeks are how a short queue becomes a long story. A queue that nobody measured and a queue that somebody complained about are the same event described twice, and only one of those two descriptions contains a number.

• Knowable: which days are non-working, straight from the notice.
• Knowable: which of your parcels have not yet been handed over.
• Knowable: what your agent says in writing about storage and about requests during the window.
• Not knowable: how many days anything will take afterwards, at any useful level of confidence.

Timing a merge around a window without a forecast

Merging is the step where optionality disappears. Once parcels are merged the order closes for changes of every kind: the parcel cannot be reopened to take a late arrival, and the address on file is the address that gets used. A holiday window does not create that rule, but it makes the rule expensive, which is why the [storage material](/table/consolidation/) treats the seal as a deadline rather than as a step.

The scenario worth planning for is a three-item parcel where one item is still with its seller when the window opens. Merging the two that arrived seals them together and leaves the third to travel alone with its own freight attached. Waiting keeps the option open and spends storage instead. The choice is between paying once for a larger parcel and paying twice for two smaller ones, and it has to be made before the window rather than during it. Storage is the cheaper of the two costs to reason about, because it is counted from intake and you can read the intake date yourself.

1. Confirm that every item you intend to merge has actually been intaken and photographed.
2. Get the storage answer in writing, including whether the window pauses the clock.
3. Decide full or partial before submitting anything, since the decision cannot be revisited after the seal.
4. Submit the merge as one action rather than as a request plus a follow-up message.

What to re-check when the next notice lands

The notice is reissued every year and the block boundaries move with the lunar calendar, so a window copied into your own calendar has a shelf life of roughly one year. The habit worth keeping is a two-line update: the new start and end dates, and which of your regular sellers actually observe the window.

• Update the boundaries from the notice itself rather than from a summary post that paraphrases it.
• Re-ask the storage question, because an answer given last year is not an answer for this year.
• Strike out any day-count expectation you wrote down last year, since none of it was ever published.

One thing does not need updating. The order of operations around a window is stable across years: intake, photographs, decision, merge, freight. The calendar changes which weeks are awkward, and it never changes the sequence in which your own choices have to be made. Knowing that the sequence is stable also tells you which questions are worth asking in the autumn rather than in the week the block starts, when nobody has time to answer them.