I have a CSV like this
timestamp,H_LOC20 (%RH),T_LOC20 (°C),P_LOC20 (Pa)
23 gen 2023 09:05:50 CET,"46,7","17,3","0,1"
23 gen 2023 09:06:00 CET,"46,7","17,3","0,1"
23 gen 2023 09:06:10 CET,"46,7","17,3","0,1"
23 gen 2023 09:06:20 CET,"46,7","17,3","0,1"
23 gen 2023 09:06:30 CET,"46,7","17,3","0,1"
23 gen 2023 09:06:40 CET,"46,7","17,3","0,1"
in Octave i use simple csv2cell to obtain a cell with all column.
How can i use the timestamp in a timeseries data?
I'm trying to use strftime with no luck
strftime is for converting a time struct to a string.
You are trying to do the reverse. The corresponding function for that is strptime
Note that octave supports two datetime-management systems, a c-based one, and a matlab-compatible one. strftime and strptime belong to the former. This shouldn't matter to you, of course, unless you want matlab compatible code, in which case you should be having a look at the datenum/datestr/datevec family. You might need to obtain all the date tokens from your string by yourself, via something like strtok or strsplit for that.
PS. To complicate things further, I believe matlab has now moved on from the above three functions to a 'Date' object based system ... but I haven't used that, and in any case it's not relevant to your situation within octave.
Related
I am trying to store the number 0.0015 in the database. I have tried float, integer but I am getting zero not the exact figure I have entered. Is there a datatype which can store such a value?
Normally you'd use DECIMAL (aka NUMERIC), with a specified scale and precision, here are the docs for it. FLOAT should also work, but you need to be aware of floating point arithmetics quirks, so DECIMAL is preferred.
Here's a dbfiddle example
If you see your data as 0 then it's either an issue with how you're inserting (maybe importing from a file) or your client rounds it down to 0 and you need to tweak it. As you can see from the dbfiddle above, it works perfectly fine.
This number (0.0015) is not representable in binary. See the following example in python:
Python 3.10.2 (tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on win32
>>> x = 0.0015
>>> (x + 1) - 1
0.0015000000000000568
This means that the storing in mysql (or any other language that converts the number to binary) will show up representation errors. You can use numeric types that doesn't do any conversion to binary, like decimal or numeric.
The code is:
var rightNow = new Date();
console.log(rightNow);
In Chrome 66 it returns:
Tue Jun 12 2018 15:36:19 GMT+0530 (IST)
In Chrome 67 it returns:
Tue Jun 12 2018 15:36:43 GMT+0530 (India Standard Time)
Why the difference?
A lot of my code works with the behaviour in chrome 66. Do I need to change all the code?
In general, you should not code for a specific browser, but to the standards. In this case, the standard is ECMAScript (ECMA-262). Section 20.3.4.41 covers Date.prototype.toString(), which refers to the following section describing the internal ToDateString(tv) function, which explains:
Return an implementation-dependent String value that represents tv as a date and time in the current time zone using a convenient, human-readable form.
By "implementation-dependent", it means that the actual string value is not defined by the specification, and can vary from one implementation to another. You are not guaranteed the same result from one browser to the next, or from one version of a browser to the next, or even from one operating system to the next from the same version of the same browser.
By "human-readable form", it means that the value produced is suitable for display to a human being. It makes no guarantees about that value being represented in a manner that can be parsed consistently by computer code.
Thus, if you intend for the string value to be sent to other code, you should not use .toString(). In general, you should prefer an ISO 8601 formatted string for this purpose. Use .toISOString() if you want the result in terms of UTC. Refer to this answer (or use a library) if you want the result in terms of local time including a time zone offset.
As to why things changed between Chrome 66 and Chrome 67 - I don't have the exact details, but I assume Chrome switched from using IANA TZDB abbreviations to using CLDR time zone names, probably through its use of ICU. This is reasonable, and is what many other implementations are doing. There's no requirement it use one set of data or the other though, so don't rely on such things.
I am trying to pass a number (date in ms) to a function in a library module. The number gets screwed up!
Here is a simple look (function MailUtils.showNum has only one line, the same log call as seen below):
n = Number(todayMs - mbRetMs);
Logger.logDebug("Num = " + n + "; as Date = " + new Date(n));
MailUtils.showNum(n);
Log:
/* Num = 1500396760628; as Date = Tue Jul 18 2017 12:52:40 GMT-0400 (EDT) */
/* Num = 1453174324; as Date = Sat Jan 17 1970 14:39:34 GMT-0500 (EST) */
Seriously ???
What the * is happening? Looks like it somehow figures out it is a date and passes the origin date (the date the ms are counted from)?
LOL, Int32 Overflow #Fail. What you’re seeing is your original [64-bit] integer's 32 Least Significant Bits; the high bits have all been stripped.
Odd in itself, since JS uses Double internally; presumably a bug in JXA. (It has a lot of those.)
If you like JavaScript I strongly recommend using Node.js instead. JXA is rubbish in comparison, and with OSA technologies now in maintenance mode I don’t imagine it’ll ever get fixed.
MINOR EDIT: I say below that JPL's Horizons library is not open source. Actually, it is, and it's available here: http://naif.jpl.nasa.gov/naif/tutorials.html
At 2013-01-01 00:00:00 UTC at 0 degrees north latitude, 0 degrees east
latitude, sea level elevation, what is the J2000 epoch right ascension
and declination of the moon?
Sadly, different libraries give slightly different answers. Converted
to degrees, the summarized results (RA first):
Stellarium: 141.9408333000, 9.8899166666 [precision: .0004166640, .0000277777]
Pyephem: 142.1278749990, 9.8274722221 [precision .0000416655, .0000277777]
Libnova: 141.320712606865, 9.76909442356909 [precision unknown]
Horizons: 141.9455833320, 9.8878888888 [precision: .0000416655, .0000277777]
My question: why? Notes:
I realize these differences are small, but:
I use pyephem and libnova to calculate sun/moon rise/set, and
these times can be very sensitive to position at higher latitudes
(eg, midnight sun).
I can understand JPL's Horizons library not being open source,
but the other three are. Shouldn't someone work out the
differences in these libraries and merge them? This is my main
complaint. Do the stellarium/pyephem/libnova library authors have
a fundamental difference in how to make these calculations, or do
they just need to merge their code?
I also realize there might be other reasons the calculations are
different, and would appreciate any help in rectifying these
possible errors:
Pyephem and Libnova may be using the epoch of the date instead of J2000
The moon is close enough that observer location can affect its
RA/DEC (parallax effect).
I'm using Perl's Astro::Nova and Python's pyephem, not the
original C implementations of these libraries. However, if these
differences are caused by using Perl/Python, that is important in
my opinion.
My code (w/ raw results):
First, Perl and Astro::Nova:
#!/bin/perl
# RA/DEC of moon at 0N 0E at 0000 UTC 01 Jan 2013
use Astro::Nova;
# 1356998400 == 01 Jan 2013 0000 UTC
$jd = Astro::Nova::get_julian_from_timet(1356998400);
$coords = Astro::Nova::get_lunar_equ_coords($jd);
print join(",",($coords->get_ra(), $coords->get_dec())),"\n";
RESULT: 141.320712606865,9.76909442356909
- Second, Python and pyephem:
#!/usr/local/bin/python
# RA/DEC of moon at 0N 0E at 0000 UTC 01 Jan 2013
import ephem; e = ephem.Observer(); e.date = '2013/01/01 00:00:00';
moon = ephem.Moon(); moon.compute(e); print moon.ra, moon.dec
RESULT: 9:28:30.69 9:49:38.9
- The stellarium result (snapshot):
- The JPL Horizons result (snapshot):
[JPL Horizons requires POST data (not really, but pretend), so I
couldn't post a URL].
I haven't linked them (lazy), but I believe there are many
unanswered questions on stackoverflow that effectively reduce to
this question (inconsistency of precision astronomical libraries),
including some of my own questions.
I'm playing w this stuff at: https://github.com/barrycarter/bcapps/tree/master/ASTRO
I have no idea what Stellarium is doing, but I think I know about the other three. You are correct that only Horizons is using J2000 instead of the epoch-of-date for this apparent, locale-specific observation. You can bring it into close agreement with PyEphem by clicking "change" next to the "Table Settings" and switching from "1. Astrometric RA & DEC" to "2. Apparent RA & DEC."
The difference with Libnova is a bit trickier, but my late-night guess is that Libnova uses UT instead of Ephemeris Time, and so to make PyEphem give the same answer you have to convert from one time to the other:
import ephem
moon, e = ephem.Moon(), ephem.Observer()
e.date = '2013/01/01 00:00:00'
e.date -= ephem.delta_t() * ephem.second
moon.compute(e)
print moon.a_ra / ephem.degree, moon.a_dec / ephem.degree
This outputs:
141.320681918 9.77023197401
Which is, at least, much closer than before. Note that you might also want to do this in your PyEphem code if you want it to ignore refraction like you have asked Horizons to; though for this particular observation I am not seeing it make any difference:
e.pressure = 0
Any residual difference is probably (but not definitely; there could be other sources of error that are not occurring to me right now) due to the different programs using different formulae to predict where the planets will be. PyEphem uses the old but popular VSOP87. Horizons uses the much more recent — and exact — DE405 and DE406, as stated in its output. I do not know what models of the solar system the other products use.
I got one issue while implementing the Ctime() in C using MS VC++ 2008 for running the application.
By using the ctime I will get current time format as Sun Jan 09 14:38:09 2011. Is there any way to convert the above format as 2012-01-09 14:38:09 (in MYSQL). Is there any direct functions in C.
Any suggestion to do this?
You can convert your time_t to a struct tm with localtime() (or gmtime()), then use strftime() to format the date as you want.
Example:
char out[20];
time_t t0 = time(0);
struct tm *tm0 = localtime(t0);
strftime(out, sizeof out, "%Y-%m-%d %H:%M:%S", tm0);
If you need different time_t values for different database columns, create them.
Then convert to struct tm and format each one as above.
Example:
time_t t0 = time(0); /* now */
time_t t1 = t0 + 3600; /* 1 hour from now */
time_t t2 = t0 + 24*3600; /* 1 day (24 hours) from now */
posted from comments to enable OP to accept as answer
According to man ctime():
The asctime() and mktime() functions both take an argument
representing broken-down time which is a representation separated into
year, month, day, etc.
I guess you can use these other functions to do what you want.
In my opinion, the one and only way to handle this (or any other) mismatch is to store the raw value returned by time() in your table; and then to let any application (including yours) format that value into any arrangement it wants to show the user.
This approach offers three big wins:
It takes advantage of the universal, simple, and well-documented time_t format, meaning you can give the db away and be sure that anybody can interpret and handle it with no further work/documentation for you. struct tm and ctime-like formats are completely arbitrary, chosen by some poor midnight programmer thirty years ago.
You avoid the well-deserved scorn and anger directed at you by anybody who wants to implement internationalization in what used to be your code.
Most important: it stores time in a format that you or anybody else can sort/select on, which is not true of any others.
It's foundational, I believe, that your table be as widely understood as you can make it. You can meet this goal by storing raw, time_t values.
There isn't one in C. Use mktime (or mktime_r) and sprintf to create your own time format.