After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 676923 - Create a GTimeZone from an offset
Create a GTimeZone from an offset
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: datetime
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-05-27 12:15 UTC by Garrett Regier
Modified: 2018-04-13 14:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtimezone: Add g_time_zone_new_offset() convenience constructor (4.45 KB, patch)
2018-04-11 16:04 UTC, Philip Withnall
committed Details | Review

Description Garrett Regier 2012-05-27 12:15:55 UTC
It would be useful to be able to create a GTimeZone from an offset instead of having to turn the offset into "+-hh:mm" format.
Comment 1 John Ralls 2012-12-18 23:59:01 UTC
Do you mean to specify an offset in +-seconds?
If you know the offset in hours you can just say "8".
Comment 2 Garrett Regier 2012-12-19 10:57:05 UTC
I know that I can just create the string myself for creating the GTimeZone, however it would be nice not having to when simply trying to create one from a known at runtime number of hours and minutes.
Comment 3 Jeffrey Stedfast 2017-03-27 13:37:49 UTC
I second this. I am looking into migrating GMime from using a time_t & an integer tz_offset to using GDateTime.

In fact, I implemented a patch to do just that last night and one of the pain points was that timezones found in Date headers tend to be of the form "+/-####" and my parer was parsing the timezone tokens as int.

I modified my code to return a GTimeZone* instead and instead of using my int-parsing logic, used g_time_zone_new() instead and let that do that parsing, but it was a bit annoying because I have to clone the token into a new string buffer as opposed to my code which handled start & end offsets within an existing string (e.g. the string that my code is parsing).

Not the end of the world and I normally wouldn't have even bothered filing a feature request, but since one is already ehre, I figured I'd chime in :)
Comment 4 John Ralls 2017-03-27 19:54:56 UTC
So are we looking for g_time_zone_new_hh_mm_offset(gint hours, guint minutes),
g_time_zone_new_sec_offset(gint seconds), both, or something else?
Comment 5 Philip Withnall 2017-04-04 08:51:44 UTC
(In reply to John Ralls from comment #4)
> So are we looking for g_time_zone_new_hh_mm_offset(gint hours, guint
> minutes),
> g_time_zone_new_sec_offset(gint seconds), both, or something else?

Probably looking for the latter:
   g_time_zone_new_offset (gint32 seconds)
that makes it match g_time_zone_get_offset(), and means it can use the zone_for_constant_offset() code in gtimezone.c as part of the constructor easily.

I’m happy to review patches, though any new API would have to be signed off by another GLib maintainer.
Comment 6 Philip Withnall 2018-04-11 16:04:11 UTC
Created attachment 370814 [details] [review]
gtimezone: Add g_time_zone_new_offset() convenience constructor

This includes tests.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
Comment 7 Emmanuele Bassi (:ebassi) 2018-04-13 13:53:17 UTC
Review of attachment 370814 [details] [review]:

Cute; okay by me.
Comment 8 Philip Withnall 2018-04-13 14:26:25 UTC
Attachment 370814 [details] pushed as cf24867 - gtimezone: Add g_time_zone_new_offset() convenience constructor