I was just recently whatching Nyall Dawson's video "QGIS 3.14 time handling and map animation demo". at min 47 (nyall dawson / youtube video min 47 ) things are getting interesting from my point of view.

While testing the "temporal controller" features I've had some confusing results when trying to implement the time dependent symbology approach shown in the video - imag_01 shows my results following the video-tutorial:

  • data: a GPS track from a yacht race in the Adriatics. data acquisition interval is about 5 min
  • point symbols (yellow): in the foreground are controlled by QGIS' temporal controller
  • points (grey): in the background are non-temporal and displayed just for giving an overview temporal controller settings are:
  • step width: 15min (= 0,25 hours)
  • the displayed interval starts at 2018-10-15 15:45:00
    and ends at 2018-10-15 16:00:00 (see the values next to "Frame:" entry)

point size is depending on a temporal expression - just like in the video: hour(@map_start_time - time_s_oesec") (see the expression in image_02) where

  • @map_start_time is the QGIS-internal variable - which should be equal to the Frame start value, i.e. '2018-10-15 15:45:00' in my example
  • time_s_oesec is a reference to the temporal field in my data - i.e. the location of the gps-tracking timestamp data (... values in the field time_s_oesec are stored without seconds in this example to keep things simple)

Since @map_start_time is the lower limit of the displayed time interval any timestamp within the interval is greater or equal @map_start_time. Scaling the yellow points (according to Nyall Dawson's video) is based on the above-mentioned expression: hour(@map_start_time - time_s_oesec).

image_01 shows my test-labels

  • 1st line: GPS point field value e.g. "time_s_osec: 15.10.18 15:50:00"
  • 2nd line: current value of the map start variable e.g. "@map_start_time: 15.10.18 15:45:00"
  • 3rd line: "@map_start_t* - time_s*: 1,92" that values should be negative due to the expresion @map_start_time - time_s_oesec and they should NOT range from > 1 to > 2 within the defined interval
  • 4.line: this is my check-value --> this value is the output from: hour(to_datetime('2018-10-15T15:00:00') - "time_s_osec" ) where '2018-10-15T15:45:00' is a fixed text which is transformed to hours based on QGIS datetime-format and should exactly correspond to the actual value of the variable @map_start_time

Obviously the expression in line 4 returns valid results - see/compare the following examples in image_01:

For the point at gps-time in the map 2018-10-15T15:45:00

  • to_datetime('2018-10-15T15:45:00') / time_s_oesec: 15:45 / result = -0,00 ... which is as expected
    but @map_start_time - time_s_oesec returns a value of 2,0

for the point at gps-time in the map 2018-10-15T15:29:00

  • to_datetime('2018-10-15T15:45:00') / time_s_oesec: 15:29 / result = 0,27
    but @map_start_time - time_s_oesec returns a value of 2,27

Summary: expressions in line 4 - which are based on the text-check-value '2018-10-15T15:45:00' return positive values for gps-timestamps before "frame start time" 15:45 (since the GPS timestamp is less than the start time) and negative values after 15:45 since it is the other way round.

While the expression hour(to_datetime('2018-10-15T15:00:00') - "time_s_osec" thus results to correct values the way the "temporal manager" handles @map_start_time in that context is strange/faulty.

But... Is it worth a bug report ?

If needed I can provide test-data


enter image description here


enter image description here

1 Answer 1


i've got a hint from rduivenvoorde on the QGIS bug reporting system (see: GitHub QGIS bug reporting issue 39393. actually it is a workaround and i am still not shure why it is working. but it works for my implementation.

according to the information on GitHub QGIS is not time-zone aware and this issue is said to be complex. following the GitHub replies data&time values are generally interpreted as UTC-values right now.

but scaling the size of the point symbols based on a time-dependent value can be implemented with this expression:

hour(@map_start_time - to_datetime(to_string( "time_s_osec" )+'Z') )


  • to_string ... changes the time-value from field "time_s_osec" into a string

  • +'Z' concats a Z ... where Z indicates "ZULU" time (yes it is called like this); ZULU time zone is exactly matching UTC time-zone !

  • to_datetime transforms back into a Date & Time value

  • and hour(@map_start_time - to_datetime(to_string( "time_s_osec" )+'Z') ) calculates the difference between the start-time of the time interval (which is depending on the time sliders position and the step value) in decimal hours

if i have got it right, it makes sense to ("manually") convert the time data from the original field into UTC-time values (e.g. into a new Date & Time field) and apply the above mentioned expression on that new and correct UTC values.

enter image description here

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.