On Mon, Mar 23, 2015 at 4:42 AM, Stef Walter <st...@redhat.com> wrote: > On 23.03.2015 12:11, Shawn Landden wrote: >> On Sun, Mar 22, 2015 at 10:32 PM, Lennart Poettering >> <lenn...@poettering.net> wrote: >>> On Thu, 19.03.15 14:39, David Herrmann (dh.herrm...@gmail.com) wrote: >>> >>>> Hmm, so this is a convenience call. You could just set tm.tm_zone >>>> locally and use mktime() with the value retrieved by "Timezone"? Yeah, >>>> the time-api is awful with global variables, but that's not really our >>>> fault, is it? >>> >>> This would not work, as struct tm's .tm_zone field is not sufficient >>> to indicate a timezone. The code would have to set $TZ and call tzset(). >>> >>> Given the simplicity of this I'd probably just merge Stef's >>> patch... It *is* kinda nice given that the timezone database is >>> constantly updated and having this exposed on the bus so that it is >>> accessible remotely has the benefit that you get the actual timezone >>> information in effect on the remote system, and not a possible >>> out-of-date timezone from the local database. If you follow what I mean... >> The patch is COMPLETELY WRONG, as timezone offsets are differn't for >> differn't times due to DST. Even if this is taken into account there >> are all sorts of races >> with this information around DST switches. > > As with the TimeUSec and RTCTimeUSec properties, it's assumed the caller > knows the information is out of date the instant they receive it. Your patch is a whole hour slow during daylight savings time. (The epoch, when you query the offset for, is standard time as it is during January.) > > But in that case I guess we shouldn't do > SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE... Fixed. > >> How about a >> "LocalTimeUSec" property, for those times that the application doesn't >> have an interest doing timezone calculations and just wants the local >> time on the other machine. > > That's fine with me. Although IMO it's quite unorthodox to have local > time in an integer value counted since the epoch. > > <snip> > > Stef >
-- Liberty equality fraternity or death, Shawn Landden ChurchOfGit.com _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel