I am interested in shrinking if possible, but am afraid that that may
reduce the accuracy. I first looked at the Natural Earth Timezone Shapefile
(
https://www.naturalearthdata.com/http//www.naturalearthdata.com/download/10m/cultural/ne_10m_time_zones.zip),
but it really does not provide the
On 11/9/20 3:48 PM, C Hamilton wrote:
> This all sounds good to me. I am guessing that we will not be able to get
> around a fairly large data set because of the need to keep the accuracy of
> the boundaries. There is a project called Timezone Boundary Builder
>
This all sounds good to me. I am guessing that we will not be able to get
around a fairly large data set because of the need to keep the accuracy of
the boundaries. There is a project called Timezone Boundary Builder (
https://github.com/evansiroky/timezone-boundary-builder) that is a detailed
On 11/9/20 12:46 AM, Nyall Dawson wrote:
> But more generally, I'd say you don't need any external library here.
> Basically the library is just doing a point in polygon lookup against
> the reference boundaries, and that's something which QGIS is already
> awesome at ;) I'd suggest you just:
> 1.
On Sat, 7 Nov 2020 at 05:50, C Hamilton wrote:
>
> This was a good discussion that I think is important and wanted to see if it
> has resulted in any development for better timezone support.
>
> Currently I have a request to provide time conversion tools and coordinate to
> timezone lookup
This was a good discussion that I think is important and wanted to see if
it has resulted in any development for better timezone support.
Currently I have a request to provide time conversion tools and coordinate
to timezone lookup capability. As I was looking at the python libraries out
there it
Hi all,
if you're going down the path of adding support for time zone
information, there is one thing that is not clear to me: If you are
planning to rely on "QDateTime" (i.e. Qt) for this purpose, you're
getting time zones based on UTC, but you're lacking support for UT1,
i.e. leap seconds and
> E.g. GDAL has a flag if a
> datetime is UTC or "not utc/unknown", and that's it.
Small precision: it also has support for explicit timezones
(like UTC+0200)
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer
On 9/9/20 2:19 AM, Nyall Dawson wrote:
> I think we have no choice but to start exposing time zone information
> to users everywhere we have dates, and move to treating dates without
> a timezone as being in "local time" (which may cause issues if
> projects + data are shared between users in
On Tue, 8 Sep 2020 at 23:40, Richard Duivenvoorde wrote:
>
> Hi Devs,
>
> I was hitting some timezone issues when I received some csv data in which
> there are timestamps like:
> "2020-07-25 20:21:38 UTC"
> Apparently if you read this into QGIS, the UTC IS interpreted, and you get a
> DateTime
I recently had some issues concerning datetimes.
Like in real life, I had to merge data from different sources, csv and
gpx, with some duplicate entries.
After a while I wondered why I couldn't find those duplicates. For some
reasons, the time values where interpreted differently while merging,
Richard,
I would second the desire to make QGIS more timezone aware. QDateTime
supports time zones so QGIS does support it, but not much effort has gone
into really supporting it. I currently have a task to do a QGIS date/time
conversion tool with algorithms to convert between different time
Hi Devs,
I was hitting some timezone issues when I received some csv data in which there
are timestamps like:
"2020-07-25 20:21:38 UTC"
Apparently if you read this into QGIS, the UTC IS interpreted, and you get a
DateTime in your data which is (in my case) -2 hours(CET) off (well in some
parts
13 matches
Mail list logo
