A PortaZone is dropped in front of you, with its nearest edge 1.5m from your current position:
When you teleport to a PortaZone, or use the "Exit this place" toolbar button to exit from it, you are teleported to a point on the back boundary of the zone opposite the drop point. Your avatar will arrive facing back across the centre of the zone towards the drop point.
In function, the various portazones are nearly identical. The only one that has any difference of significance is the casual portazone, which is free to refill, has a limit on the extent to which it can be refilled and of course fewer available drops (5 vs. 30 for the other types).
If you drop a portazone, there is a parameter (ObstacleDasp? code=38 under activobExtras) called dropMinutesRemaining?. This appears to "stick" at the number of minutes left on the zone when it was dropped; it does not appear to decrease. An adjacent parameter dropPaidThrough? seems to be the retrieval time. I dropped a fully-charged casual zone twice, two minutes apart, and got a difference of around 3600 in retrieval times. This implies a scale of 30 ticks (simulation steps?) per second.
Recharging the casual in-world results in the dropMinutesRemaining? sticking at 240 and the dropPaidThrough? incrementing. Dividing the tick-based simulation deadlines by 30 appears to give Unix UTC "seconds since the epoch" with no timezone adjustments (i.e., I get the right answer even though I am eight time zones away from the server).
A newly planted scroll shows dropMinutesRemaining? of 0 and dropPaidThrough? an hour in the future. Perhaps documents are only scanned for retrieval every so often? A book that has been sitting around for a bit longer shows up as having a dropPaidThrough? several hours in the future but still short of the real deadline. I haven't seen a number for that window being larger than 64800 on a document... maybe they are trying to keep it in 16-bits worth of seconds?
Interestingly, a portazone always shows the correct timeout date/time even if it is many days in the future.
Charging an in-world medium portazone results in the appropriate incrementing of dropPaidThrough? and the setting of dropMinutesRemaining? to the number of minutes from the recharge time to the expiry time.
The expiry time for a PortaZone is extended when the system is down. For example, if a PortaZone is in-world when the system goes down for an hour, its dropPaidThrough? will be appear to have been extended by an hour when examined after the system comes up. We are told that "different servers can have different amounts of downtime, even for portazones in the same sector" but it isn't clear exactly what that means.