Re: definative way to place secs from epoc into timestamp

>
> Unix time stamps, short (int) or long res, are always supposed to GMT
> based, as far as I know - I never seen anything different, except maybe
> in homebrew software. So it should be both calendar and P.I.T. And you
> wouldn't need the TZ storage if the date-number and number-> translation
> itself takes the TZ arg so that it can localize the Human String for you.
>
> Ken
>

In fact, I would suggest that if there is any function, or field, that
takes a TZ-less argument (*especially* if it takes only the number),
that its name should be made to contain 'UTC' so clearly disambiguate
whats its intended use for (since zone-less values/fields SHOULD be
regarded as UTC) - Otherwise, some users will place epoch numbers
adjusted for the their timezone in the field (and even with daylight
saving offsets applies, somewhat amusingly but wrong). So then two
different users are using the exact same datatype for inconsistent
types. (just a concern for interoperability, user awareness, and when
an employee comes on-board and has to deal with bad legacy)