I'm using QGIS 2.16.3 and attempting to convert a number of datetime fields that are appearing in the incorrect default GMT +0 timezone. I would like to add, for example, 10 hours to accurately reflect the time zone of data collection.

So far I've attempted using the field calculator:

"Date_Field" +   ('10:00:00')

which just adds a string to the end (i.e. '2017-4-06 14:00:001')

I've also tried:

( "Date_Field") + to_time('10:00:00')
( "Date_Field") + to_datetime('10:00:00')  
to_datetime( "Date_Field") + to_datetime('10:00:00')

which gives me an error "Cannot convert '2017-04-06 14:00:00' to double", although I am able to convert the datetime field alone.

This seems like a simple, common operation for anyone working with different time zones. My only workaround is to create a CSV and edit the fields in a spreadsheet.

  • How are you storing this information? Is your underlying DB compatible with timestamps or is the information simply kept as a string? Commented Apr 17, 2017 at 12:51
  • This can also help. Commented Apr 17, 2017 at 12:59
  • 2
    How about to_datetime("Date_Field") + to_interval('10 hours') ?
    – Kazuhito
    Commented Apr 17, 2017 at 13:08
  • I'm using a shapefile exported from a proprietary database but compatible with timestamps. When I created a new string field with to_datetime( "Date_Field" ) I am able to use Time Manager on that field but not do any calculation. Commented Apr 17, 2017 at 13:24
  • 1
    Thanks @Kazuhito , to_interval successfully added 10 hours! Commented Apr 17, 2017 at 13:27

1 Answer 1


Expression to_datetime("Date_Field") + to_interval('10 hours') will add 10 hours to the "Date_Field".

I have not tested fully, but it seems to_interval() accepts month(s) day(s) hour(s) and their combinations such as '1 day 2 hours'.

  • 1
    Thanks @Kazuhito , this worked perfectly. It also accepted the combination '10 hours 01 minutes' Commented Apr 17, 2017 at 15:14
  • @nickislander I am glad it worked. Thanks for the minutes tip, too.
    – Kazuhito
    Commented Apr 17, 2017 at 16:24
  • 1
    Bravo @Kazuhito! A follow-up thought: If daylight savings time shifted during the period that the original data was collected (say the offset changed from -8 to -7), then the user would need to apply the expression twice - once for just those records in the -8 period, then a second calculation for the -7 period records. I have not tested, but this seems reasonable.
    – Stu Smith
    Commented Sep 18, 2018 at 18:01
  • Thanks @StuSmith. I agree with you. Perhaps keeping all of "UTC", "UTC-8h", "UTC-7h" fields in the attribute table will be helpful (and self-explanatory). Both time zones and DST time-shift are quite error-prone.
    – Kazuhito
    Commented Sep 18, 2018 at 20:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.