OmniPM

Dates and currency

Calendar days in JST, and whole yen. Both conventions have consequences.

Two conventions run through everything, and both explain behaviour that looks odd until you know them.

Dates are calendar days, in JST

A move-in day, a contract end, a billing month boundary — these are calendar day concepts, not moments in time. They are anchored to Japan Standard Time, and JST has no daylight saving, so a day is always a day.

What follows from that:

  • A date has no time of day. A move-out "on the 31st" means the whole of the 31st. There is no hour at which it takes effect.
  • A date does not shift for the viewer. Someone reading the dashboard from another country sees the same dates as someone in Tokyo. They are properties of the tenancy, not of the reader.
  • Month boundaries are JST calendar boundaries. This is why proration uses the real number of days in the month — see Proration.

Timestamps are different

Some values genuinely are moments: when an invoice was sent, when a payment landed, when someone was forced to month-to-month. Those are instants, recorded to the second, and they are audit trail rather than policy.

The distinction matters when you compare two things. A filed-on timestamp and a move-out calendar day are different kinds of value, and "is the notice before the move-out?" needs the calendar day on both sides. Notice periods are counted in whole days for exactly this reason.

Money is whole yen

Every amount is a whole number of yen. There are no sub-yen fractions in the money path, and nothing is stored as a floating-point value.

Consequences worth knowing:

  • Rounding happens per line, not per total. Each component of a prorated period is rounded on its own and the total is their sum. That is why an itemised prorated invoice can differ by a yen from the same month multiplied out on a calculator — and the itemised figure is the correct one, because it is what the resident is actually billed, line by line. See The ledger.
  • A one-yen discrepancy is usually arithmetic, not an error. Before chasing it, check whether you are comparing a sum of rounded parts against a rounded whole.

Where percentages live

A few things are configured as percentages rather than amounts — a fee derived from a share of rent, for instance. The percentage is stored precisely; the yen amount it produces is rounded to a whole yen at the point it becomes a charge. So the rate is exact and the money is an integer, which is the right way round.

Reading an amount anywhere

Amounts display with a yen symbol and thousands separators. A figure shown without them in an export is the same number — formatting is presentation, and the stored value is the integer.

Never enter an amount with decimals, and never paste a figure carrying a currency symbol into an amount field. Both are signs you are working from a formatted display rather than the underlying number, and the mismatch tends to surface later as a reconciliation problem rather than immediately as a validation error.

See also Proration and Contract dates.

On this page