On Wed, Apr 02, 2014 at 05:44:16AM -0600, Eric Blake wrote: > On 04/02/2014 03:34 AM, Michal Privoznik wrote: > > If we'd come up with a struct to interpret the time, it's written > > in stone and there's nothing we can do about it. Even if we break > > up the struct into function arguments. However, we can use typed > > parameters and have the API extensible. For example, I'm > > implementing seconds granularity only for now. If later somebody > > feels like he/she wants to use even finer granularity, we can do > > that by inventing a new typed param. Same goes for timezone, etc. > > But what more is there to add besides seconds and nanoseconds (struct > timespec)? We don't have to support full resolution of nanoseconds, and > could either document that we round (possibly to as course as seconds) > or reject input with non-zero nanoseconds if we don't want to support > sub-seconds right away. It just feels awkward to me to have to bundle > something into a virTypedParam when the most we could ever extend this > to is struct timespec, so representing struct timespec via split > parameters from the get-go requires less thought when using the interface. I think I'm inclined to agree that we shouuld just use an long long timesecs and possibly a second long long timenanosecs. People won't normally update the timezone at the same time as updating the BIOS time and vica verca. So in the event we ever wanted to update the timezone I could see that being a separate virDomainSetGuestTimezone API. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list