Select to view content in your preferred language

TimeSlider connected to columns containing milliseconds instead of UTC Date

981
3
Jump to solution
04-02-2013 05:36 AM
ghostbanderas
Occasional Contributor
Hi

I'm having problem using TimeSlider (ArcGIS online), which shows data according to date columns (type: esriFieldTypeDate , alias: DateFieldFrom , length: 8; type: esriFieldTypeDate , alias: DateFieldTill , length: 8).

I think, that the main problem is, that when I use query, the result for the Date columns is something like this:
1056468000000
1112103600000
1060897600000
It's obvious, that these are milliseconds.

I'm using this example:
http://help.arcgis.com/en/webapi/javascript/arcgis/jssamples/time_sliderwithdynamiclayer.html
I've just changed the rows with my relevant data: e.g. map service address, layerDefinition and so on.
I'm displaying data week by week.

Am I right, that the milliseconds data could by the cause, why the TimeSlider is not working ? I can run the TimeSlider, but nothing happens on the map. Yes, there should be changes within the time period that I'm running the TimeSlider.
The other suspicious thing is the date length. In case of UTC length 8 is probably not enough.
The last thing I can think off is, that the map service doesn't have TimeZone set to UTC. TimeZone is blank.

The last catch is, that I'm just using a map service created by someone else, I can't change the map service by myself. So I need to convince this person, that these milliseconds are not OK and that an UTC date format is needed.

Maybe there is some solution to work this using javascript, but I haven't found any. Help would be appreciated.

Thank you
gC
0 Kudos
1 Solution

Accepted Solutions
ghostbanderas
Occasional Contributor
Problem solved.
The TimeSlider is OK.
The dates in milliseconds are OK.
The "DateFrom higher than DateTill is higher" issue is probably solved too. Seems to be the problem of exporting data from excel to csv and arcgis.
My knowledge about arcgis api for javascript is very low, so that's the reason of the previous questions.

View solution in original post

0 Kudos
3 Replies
ghostbanderas
Occasional Contributor
I forgot to mention one important information: I'm drawing country borders, not points.
The borders are part of the layer definition.

My map service contains two layers, feature layers.
There was a rowcount restriction to 1.000 rows, so we changed it to 1.000.000, but the timeslider is still not working.

Any help would by highly appreciated.
Thanks

P.S. We've figured out, how to write the query for the date column, it's for example: dateColumn = date'01/01/2012'
0 Kudos
ghostbanderas
Occasional Contributor
I've run through another data analysis and the results are weird.
I've run query on my layer and the date column values are probably incorrect.

If I look into our database for the date columns, the data is correct.
I have date columns: DateFrom, DateTo, which means DateFrom < DateTo.

Result of the rest query is this:
ROW1:
DateFrom:1159488000000
DateTo    :1149897600000

Since I presume, that this values are milliseconds since 01.01.1970, then DateFrom value in milliseconds should be lower than DateTo value. Am I right ?

Other rows:
ROW2: looks ok
DateFrom: 1160092800000
DateTo    : 1160697600000

ROW3: looks ok
DateFrom: 1160697600000
DateTo    : 1161302400000

ROW4: looks ok
DateFrom: 1161302400000
DateTo    : 1161907200000

ROW5: wrong ! DateTo is lower than DateFrom
DateFrom: 1161907200000
DateTo    : 1142035200000

ROW6: wrong again
DateFrom: 1162512000000
DateTo    : 1160524800000

ROW9: wrong ! DateTo is lower than DateFrom
DateFrom: 1164326400000
DateTo: 1137024000000

Can you tell me please, what could be the reason of this date situation and how to solve it ?
0 Kudos
ghostbanderas
Occasional Contributor
Problem solved.
The TimeSlider is OK.
The dates in milliseconds are OK.
The "DateFrom higher than DateTill is higher" issue is probably solved too. Seems to be the problem of exporting data from excel to csv and arcgis.
My knowledge about arcgis api for javascript is very low, so that's the reason of the previous questions.
0 Kudos