On Fri, 2016-08-12 at 23:02 +0200, Gert Doering wrote: > This is a good argument. Unfortunately, it's a surprisingly *hairy* one, > as there are time zones that do not have a full-hour offset - so ISO 8601 > (according to wikipedia) says you should do "±hh:mm" then - and for > most folks, ":mm" would always be ":00", sort of waste of screen real > estate...
You would definitely want to use the standard format that you see every
day in email, and as you see it above: +0200.
> Regarding portability, this is even more interesting. I assumed that
> localtime()'s "struct tm" would be truly portable, but it seems that
> older unixes have "long tm_tzadj; /* seconds from UTC */" while
> modern ones have "long tm_gmtoff; /* offset from UTC in seconds */"
> (WHY OH WHY???)....
>
> * TZMINS_USE_xxxxxx specifies how to get timezone offset.
> *
> * TZMINS_USE_TM_TZADJ use (struct tm*)->tm_tzadj
> * TZMINS_USE_TM_GMTOFF use (struct tm*)->tm_gmtoff
> * TZMINS_USE_TZAZ_GLOBAL use "timezone, altzone" externals
> * TZMINS_USE_TZ_GLOBAL use "timezone" external
> * TZMINS_USE_FTIME use ftime() function
> * TZMINS_USE_TIMEOFDAY use gettimeofday() function
>
> ... from ports/elm/lib/get_tz.c...
>
> (I don't think anything but tzadj/gmtoff is relevant anymore today, but
> need to check more systems. And no, strftime() isn't helping - it
> has "%z", which, according to FreeBSD's man page is an extention to
> the C90 standard...)
Yeah, I once made git use strftime("%z") but that is... handled
differently now.
time(&now);
offset = tm_to_time_t(localtime(&now)) - now;
offset /= 60;
Where tm_to_time_t() is basically mktime() except that *that* has
bizarre issues on some platforms too. But fundamentally, comparing
gmtime(now) with localtime(now) might be the way to go.
The alternative option is just to *always* log in UTC, of course... :)
--
dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. http://sdm.link/zohodev2dev
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
