On 02/16/2012 07:12 PM, Guy Harris wrote:
At least one system that is a UNIX(TM):
http://www.opengroup.org/openbrand/register/brand3581.htm
has - not surprising, given its BSD heritage - timezone()-as-a-function, so, actually, POSIX/the Single Unix Specification *doesn't* require it.
I suppose, given the lack of buildbot and user complaints, that this
function is, as it is on Linux, wrapped in an #ifdef.
If the goal is to have a function that is to mktime() as gmtime() is to localtime() - i.e., that converts a UTC-style date/time specification of year/month/day/hour/minute/second into a so-called "seconds since the Epoch" value (which is not actually a count of the number of seconds that have elapsed since the Epoch, as the), try this bit from the Single Unix Specification:
4.15 Seconds Since the Epoch
A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below.
If the year is<1970 or the value is negative, the relationship is undefined. If the year is>=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, andtm_year are all integer types:
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year -69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
The problem with that is we'd need to calculate tm_yday which, while
fairly straight forward, is annoying. Unfortunately the timezone field
I saw in struct tm isn't guaranteed to be there, either, so yet another
method is to just call gmtime() and localtime() and calculate the
(current) timezone offset (the current one is what we want anyway as
that's what mktime() is applying). I'll check that in shortly.
At least as I read section 4.7.23.4 "Absolute Time Format" of the SMPP V5.0 spec, an Absolute Time Stamp has a (non-Y2.1K-safe!) date/time value that I infer from "in UTC format" is UTC, plus an indication of the time zone offset from local time (presumably the time zone offset *at the specified time* - the offset, of course, varies over time). If so, then, yes, you want said function.
The introductory paragraph says that, but the explanation of the offset
says that the time is a local time and the offset of that local time
from UTC is given (emphasis mine):
Time difference in quarter hours between local
time (*as expressed in the first 13 octets*) and
UTC (Universal Time Constant) time (00-48).
So, skipping back a quote or two, the goal/ideal function would actually
be a mktime() that takes, as input, the timezone as an offset from UTC.