I'm unable to find any examples on how to write a CF-compliant NetCDF with a time coordinate variable of type np.datetime64. The timesteps were originally as pd.Timestamp's but got automatically converted. I don't really think in terms of nanoseconds elapsed since the epoch or whatever, so could someone please point me to how I can make the conversion painlessly and produce a CF-compliant .nc?
Thanks
Related
I'm trying to plot a graphic that displays values against moments of time.
For this, I have an array of time instants (in Epoch) and an array of values.
I've already been able to plot the graphic normally using the raw time (as Epoch). The problem is specifically in the conversion of the axis time format.
hold on;
plot(horizontal, pre_X(:,4), 'b-');
xt = get(gca, 'xtick');
set(gca, 'xticklabel', sprintf('%d|', xt));
datetick ("x", "dd/mmm/YY HH:MM");
yt = get(gca, 'ytick');
set(gca, 'yticklabel', sprintf('%d|', yt));
hold off;
The datetick function was supposed to be able to transform these Epoch times into nicely formatted ones, but I am not getting the expected result. Instead, all time instants get labeled as the same (01/JAN/00 00:00) which is weird.
The plot without the
datetick ("x", "dd/mmm/YY HH:MM");
line works fine, but gives the time information in Epoch, which is not what I intend to.
Any help would be appreciated!
NOTE: If the right function to do what I intend to turns out not to be "datetick", also please let me know! All I need is to get the X axis to be formatted nicely into readable time.
EDIT: By Epoch Time, I mean Unix Time.
Lacking more info, I'm going to assume that by Epoch time you mean posix, or Unix time
I would expect that to then be represented as a 32-bit integer, and should be the number of seconds counted from 'zero time' (as described in the Wiki linked) (it may also be a floating point number including fractional seconds using the same scale).
According to the Matlab help for datetick, it expects the axis data to be "serial date numbers, as returned by the datenum function". For compatibility, octave likely expects the same, although the datetick function reference does not state such explicitly.
The datenum "serial date number" format is another serial representation of time, but it has a different scale and reference than Epoch/posix/unix time. According to the datenum function description, it's serial definition is "date/time input as a serial day number, with Jan 1, 0000 defined as day 1".
That's a long way of saying you're time is probably in units of seconds, whereas datenum expects units of days.
Now, you can probably address this a couple ways. you can covert all of your times to the datenum scale before plotting. from this example, something like this would work in Matlab:
datetime(1470144960, 'convertfrom','posixtime')
According to bug #47032 datetime has not yet been implemented in Octave, but that bug report does link to a github repository with a datetime class implementation (under the inst/ folder).
To manually convert from unix to matlab time, you could convert following this example from the Mathworks File exchange:
unix_epoch = datenum(1970,1,1,0,0,0);
matlab_time = unix_time./86400 + unix_epoch;
(assuming your x-axis data is the unix_time variable)
Once you get your data into the 'datenum' scale, datetick should perform correctly.
I have not worked with SPSS (.sav) files before and am trying to work with some data files provided to me by importing them into R. I did not receive any explanation of the files, and because communication is difficult I am trying to figure out as much as I can on my own.
Here's my first question. This is what the Date field looks like in an R data frame after import:
> dataset2$Date[1:4]
[1] 13608172800 13608259200 13608345600 13608345600
I don't know what dates the data is supposed to be for, but I found that if I divide the above numbers by 10, that seems to give a reasonable date (in February 2013). Can anyone confirm this is indeed what the above represents?
My second question is regarding another column called Begin_time. Here's what that looks like:
> dataset2$Begin_time[1:4]
[1] 29520 61800 21480 55080
Any idea what this is representing? I want to believe this is some representation of time of day because the records are for wildlife observations, but I haven't got more info than that to try to guess. I noticed that if I take the difference between End_Time and Begin_time I get numbers like 120 and 180, which seems like minutes to me (3 hours seems reasonable to observe a wild animal), but the absolute numbers are far greater than the number of minutes in a day (1440), so that leaves me puzzled. Is this some time keeping format from SPSS? If so, what's the logic?
Unfortunately, I don't have access to SPSS, so any help would be much appreciated.
I had the same problem and this function is a good solution:
pss2date <- function(x) as.Date(x/86400, origin = "1582-10-14")
This is where I found the answer:
http://scs.math.yorku.ca/index.php/R:_Importing_dates_from_SPSS
Dates in SPSS Statistics are represented as floating point doubles holding the number of seconds since Oct 1, 1582. If you use the SPSS R plugin apis, they can be automatically converted to R dates, but any proper converter should be able to do this for you.
is there a way to use WMS->GetFeatureInfo specifying a TIME period (eg: 2014-01-01/2014-03-01) to extract a series of values from a raster layer loaded from a GeoServer instance?
Thanks in advance
Not at the moment, no. It may be added in the future though, it's not the first time I hear this request. I don't have a ETA, it depends on when funding to work on it shows up.
In the meantime, a somewhat complex workaround might be to configure the image mosaic index as a WFS feature type, query it by date, figure out the exact time values intersected by the interval, and then do N GetFeatureInfo requests, one for each of those values.
I am trying to plot data from a simulation that tracks simulation time in (hours):(minutes):(seconds) format, but does not turn (hours) into days - so (hours) can be in the hundreds. When gnuplot plots data by time, however ("set xdata time"), it only plots up to 99 hours in one continuous plot; after that, it loops back around and starts overplotting hour 100+ near the beginning (and even then, does weird stuff). Does anyone know why this happens and/or how to get around it?
I also looked into reading the components of the time column (which is the 3rd field of data on each line, but not necessarily a fixed number of characters into the line) in as 3 simple numbers (integers), then converting to a real number, which happens to be a decimal version of the time (e.g., 107:45:00 -> 107.75), which would be fine for the plot, but I haven't been able to figure out how to get gnuplot to do that, either.
Any other ideas are welcome. (I would rather not alter the original file, due to the additional complexity of multiple versions of each file, having to teach others how to convert the file and how to figure out the plot didn't work because they didn't convert the file, etc.)
Version 2 of MathGL (GPL plotting library) have time ticks which can be set as you want (using standard strftime() format). However it is in beta version now -- stable version should appear at October 2011.
I am working on a project that involves converting data into dos date and time. using a hex editor (Hex Workshop) i have looked through the file manually and and found the values I am looking for, however I am unsure how they are calculated. I am told that the int16 value 15430 corresponds to the date 06/02/2010 but i can see no correlation, also the value 15430 corresponds to the time 07:34:12 but i am lost in how it is calculated. any help with these calculations would be very welcomed
You need to look at the bits in those numbers.
See here for details:
http://www.vsft.com/hal/dostime.htm
I know this post is very old but I think the time 07:34:12 corresponds to 15436 (not 15430).