Open chatchavan opened 4 years ago
This seems like a pretty big issue.
This seems like a pretty big issue.
I don't think it's is critical problem - from top of my head this can happen only when setting a date in the query. Otherwise (when asking a time for today), it should be working fine.
Still worth to check though.
Best regards, Jarek
Took a look at timezone_list.sh and from the code snippet below:
#
# create source date
#
if [ 'tm' = "$date_modification_search" -o 'tomorrow' = "$date_modification_search" ]
then
dateToConvert=$(date -v +1d +%Y%m%d)
elif [[ "$date_modification_search" =~ ^[0-9]+d$ ]]
...
(The full date handling logic is in timezone_list.sh:72-99)
Whenever a date is entered, the script uses the -v flag for the date command to create an offset. From the date man page under the -v flag:
When a date is adjusted to a specific value or in units greater than hours, daylight savings time considerations are ignored. Adjustments in units of hours or less honor daylight saving time. So, assuming the current date is March 26, 0:30 and that the DST adjustment means that the clock goes forward at 01:00 to 02:00, using -v +1H will adjust the date to March 26, 2:30. Likewise, if the date is October 29, 0:30 and the DST adjustment means that the clock goes back at 02:00 to 01:00, using -v +3H will be necessary to reach October 29, 2:30.
So seems like you're right @jaroslawhartman, this is only a problem when the date is entered. As shown below, without a date offset that flag isn't used so DST considerations are kept.
else
# fallback that also covers 't' and 'today'
dateToConvert=$(date +%Y%m%d)
fi
Example: Zurich (Switzerland) will begin the daylight saving time on 29 March 2020.
I have a quick look at the code and cannot find any file that keep the data on daylight saving time, so I guess that the change may be non-trivial.