I am trying to make a script which convert BUS master .log files into .asc files without bus master. The files are just column adjustment but I am stuck with different time format used in the files' format.
Example: 11:29:26:2229 (.log) = 41366.222900 (.asc)
Please help me out to understand the .asc file time format.
In the header of the .asc file, the start time and date is given in the very first line. E.g.:
date Mon Okt 24 10:01:03 2022
The timestamps of the individual CAN messages (and other events) are just offsets to the start time in seconds. I.e. given the header above, the timestamp
123.456
Would be 123 seconds and 456 milliseconds after 10:01:03, which is 10:03:06.456
Details about the .asc format can be found in the Doc folder in CANoe's installation directory.
.asc time format = hour * 3600 + min * 60 + sec.
Related
I am unable to understand the expiry date format of the JWT embedded in my application.
For example: 1473912000
What does this translate to? 1473912000 ms, some x date? Any help will be appreciated!
Like James has pointed out:
The number is the number of seconds since Jan 1 1970.
This is converted into the Date object in a quite straight-forward way (the *1000 part is here because in JS main time unit is millisecond):
const expiryDate = new Date(1473912000*1000);
Then you can use any Date method you please.
Likewise, in Ruby you can use Time.at(1473912000) to create a new Time instance like Maxim has shown.
The number is the number of seconds since Jan 1 1970. It is commonly used on unix systems to represent time. Your time is 2016-09-15 04:00 (UTC)
To convert you can try a web based system http://www.unixtimestamp.com/index.php
This is UNIX time in seconds:
➜ ~ irb
2.2.0 :001 > Time.at(1473912000)
=> 2016-09-15 07:00:00 +0300
Two computer install centos 6.5, kernel is 3.10.44, have different result.
one result is [u'Asia/Shanghai', u'Asia/Urumqi'], and the other is ['Asia/Shanghai', 'Asia/Harbin', 'Asia/Chongqing', 'Asia/Urumqi', 'Asia/Kashgar'].
Is there any config that make the first result same as the second result?
I have following python code:
def get_date():
date = datetime.utcnow()
from_zone = pytz.timezone("UTC")
to_zone = pytz.timezone("Asia/Urumqi")
date = from_zone.localize(date)
date = date.astimezone(to_zone)
return date
def get_curr_time_stamp():
date = get_date()
stamp = time.mktime(date.timetuple())
return stamp
cur_time = get_curr_time_stamp()
print "1", time.strftime("%Y %m %d %H:%M:%S", time.localtime(time.time()))
print "2", time.strftime("%Y %m %d %H:%M:%S", time.localtime(cur_time))
When use this code to get time, the result of one computer(have 2 results) is:
1 2016 04 20 08:53:18
2 2016 04 20 06:53:18
and the other(have 5 results) is:
1 2016 04 20 08:53:18
2 2016 04 20 08:53:18
I don't know why?
You probably just have an outdated version of pytz on the system returning five time zones (or perhaps on both systems). You can find the latest releases here. It's important to stay on top of time zone updates, as the various governments of the world change their time zones often.
Like most systems, pytz gets its data from the tz database. The five time zones for China were reduced to two in version 2014f (corresponding to pytz 2014.6). From the release notes:
China's five zones have been simplified to two, since the post-1970
differences in the other three seem to have been imaginary. The
zones Asia/Harbin, Asia/Chongqing, and Asia/Kashgar have been
removed; backwards-compatibility links still work, albeit with
different behaviors for time stamps before May 1980. Asia/Urumqi's
1980 transition to UTC+8 has been removed, so that it is now at
UTC+6 and not UTC+8. (Thanks to Luther Ma and to Alois Treindl;
Treindl sent helpful translations of two papers by Guo Qingsheng.)
Also, you may wish to read Wikipedia's Time in China article, which explains that the Asia/Urumqui entry is for "Ürümqi Time", which is used unofficially in some parts of the Xinjiang region. This zone is not recognized by the Chinese government, and is considered a politically charged issue. As such, many systems choose to omit the Urumqi time zone, despite it being in listed in the tz database.
I am using ESPER to read events from a CSV file.
How can I make the query output something when reading a CSV file is finished.
For example i want to output every 30 min or at the end of the file
SELECT id FROM stream output every 30 min or [ EOF reached ]
Thanks in advance
Regards
The "adapter.start()" finishes when the CSV file is done and the code can send a EOF event into the engine. You could declare a context that ends on that EOF event and there is a "output every 30 minutes and when terminated" option.
A build that takes about three hours to complete needs to be scheduled for nightly building outside office hours: not sooner than 22:00 and not later than 3:59 next day.
I'd also like to use the "H symbol" to avoid collision with future nightly builds. From in-line help in Jenkins:
To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.
(How) can I schedule this using Jenkins? What I've tried was all considered invalid by Jenkins:
H H(22,23,0,1,2,3) * * *
Invalid input: "H H(22,23,0,1,2,3) * * *": line 1:7: expecting "-", found ','
H H22,23,0,1,2,3 * * *
Invalid input: "H H22,23,0,1,2,3 * * *": line 1:4: unexpected token: 22
H H(22-3) * * *
Invalid input: "H H(22-3) * * *": line 1:9: 1 is an invalid value. Must be within 1
and -18
Is it possible to achieve this without using plug-ins?
I think the closest you will get is to use:
H H(0-3) * * * This will run at some point between 0:00 and 3:59
#midnight This will run at some point between 0:00 and 2:59
The H(4-8) construct only works if the second items is larger then the first.
But you might as well fill in the hour yourself. Jenkins actually never changes the hour the jobs runs once it is set. It will basically create some random hour once you save the job and always run the job at that particular time.
Of course, you can also file a bug report or feature request that you should be able to specify this as H(22-3) or better, fix the code and submit a patch ;)
There is no direct support to write the expression like this, but since there is timezone support (now), you can work around this.
# DONT COPY PASTE - THIS DOESNT WORK!
# This is what we would like to write, but is not supported
H H(22-3) * * *
Above expression means we want to build somewhen between 22 PM and 3 AM, this is a 5 hour period, so we could write:
# Assuming we're in GMT+2 we can just shift the timezone
# so 22-03 becomes 10-15 wich is 12 hours earlier so the
# timezone is GMT-10
TZ=Etc/GMT-10
H H(10-15) * * *
I found this workaround in the comments of JENKINS-18313
UPDATE:
There is currently a bug JENKINS-57702 and the timezone GMT-XX is not evaluated correctly. A workaround is to use a equivalent timezone, in this example the one for Hawaii:
TZ=US/Hawaii
H H(10-15) * * *
I'm trying to run a PHP script from CRON every 15 minutes from 9AM to 6PM during Monday to Friday. My problem is the server is set to CST and my client is on GMT+8. I believe (please do correct me if I'm mistaken) we have a time difference of 13 hours. I'd like to check if the following settings are correct:
*/15 20-23 * * 2-7 wget -O - http://www.mysite.com/myscript.html
*/15 00-05 * * 2-7 wget -O - http://www.mysite.com/myscript.html
Pardon me. This is the first time I'm using CRON.
Thanks in advanced.
What you have looks OK except when daylight saving time changes occur. What will you do then? One option is to expand your window by an hour so that you run the job for an extra hour on one side during winter and the other side during summer. If that's not OK for some reason, you'll need to either change the server's timezone, change your script to check the time, or use this patch from OpenSolaris, which adds special TZ support to cron:
http://blogs.oracle.com/chrisg/entry/timezone_aware_cron_finally_pushed