I am developing a J2ME GPS tracking software. I am testing it on LG Touch Screen and i get the wrong timestamp. it's 10 years and 5 days different than the current date(now it show 2000 not 2010). I have done some search and see some people say there's some bug in LG GPS timestamp.
Can anyone give me some advice on the work around for this? Advice and suggestion are much appreciated
Thanks
The GPS epoche is Jan 6, 1980. The UTC epoch is Jan 1, 1970. Most phones use GPS and most PCs use pseudo-UTC. I use the prefix pseudo to say that UTC time accounts for leap seconds that are currently 16 different than the straight conversion of GPS to UTC (as of Oct 2012). PCs are usually updated from internet sources (so PC are lucky to be able to opt out of this 16 secs issue).
Time = Unix timestamp format. I added 64800 second to the time so it would be converted to Mountain Standard Time.
*timestamp
24 * 60 * 60
.getTime()//milliseconds
24 * 60 * 60 * 1000
private DateField dateField1;
///////////////////////
dateField1= new DateField("Date:", DateField.DATE);
f.append(dateField1);
Date d = new Date();
dateField1.setDate(d);
String TimeSeg = String.valueOf(((dateField1.getDate().getTime()/1000)+64800));
Related
I'm making use of open trip planner using the jython scripting method explained here: http://docs.opentripplanner.org/en/latest/Scripting/
(specifically 'Using OTP as a library') and am using a script very similar to their example script
For testing purposes I have two csv files containing 40 locations each. The locations are inside the Netherlands and I have loaded both the dutch gtfs and map. The strange thing is that the code that calculates the public transport trip times (line 32 in the example script: res = spt.eval(colleges), using modes WALK,TRANSIT) takes longer when I specify a day other than today.
An example:
req.setDateTime(2018, 12, 8, 16, 00, 00) # today
spt.eval(my_data) # -> takes ~7 - 10 seconds
req.setDateTime(2018, 12, 7, 16, 00, 00) # yesterday
spt.eval(my_data) # -> takes ~30 - 40 seconds
When not setting req.setDateTime(), spt.eval() is even faster. Note that I ran the script on the 6th, for the 6th, as well, and it was fast then too, so it's certainly related to "today" and not specifically the 8th.
Of course my primary question is, how do I make it fast for days other than today? (my main interest is actually tomorrow)
Is it related to when the OTP instance is started or is it some internal optimization? I don't think it's related to the building of the graph because that was built a couple of days ago. I was looking into providing a day or datetime setting when initializing OTP but am unable to find that in the docs.
(I haven't tried messing with my system time yet, but that's also an option I'm not very fond of). Any ideas or comments are welcome. If necessary I will provide a reproducible sample tomorrow.
This problem was actually caused because of how I used req.setDateTime() in combination with req.setMaxTimeSec().
Basically, setMaxTimeSec() uses the date set by setDateTime() as a starting point, and defines a worstTime (aka the last possible time) to that date time + the maxTimeSec. However, if setDateTime() was not yet set when calling setMaxTimeSec(), the current date time is used instead. This will consequently cause problems when you happen to call setDateTime() AFTERWARDS. Example:
setMaxTimeSec(60*60) # Sets worst time to now + 1 hour
setDateTime(yesterday) # Sets departure time to yesterday
This example has a very long time window to search for solutions! Instead of only looking within an hour time, we are now looking in a window of 25 hours!
Anyway, a simple solution is to first call setDateTime(), and then setMaxTimeSec():
setDateTime(yesterday) # Sets departure time to yesterday
setMaxTimeSec(60*60) # Sets worst time to yesterday + 1 hour
Alternatively, if, for some reason, you can't switch these methods, you can always correct the setMaxTimeSec() with the time difference between now and your setDateTime()-value:
date = datetime.strptime('2019-01-08 21:00', '%Y-%m-%d %H:%M')
date_seconds = time.mktime(date.timetuple())
now_seconds = time.mktime(datetime.now().timetuple())
date_diff_seconds = int(round(date_seconds - now_seconds))
req.setMaxTimeSec(60*60 + date_diff_seconds)
req.setDateTime(date.year, date.month, date.day, date.hour, date.minute, 00)
I want to know that is there any command which can provide time without DST if DST is applicable in the zone.
I have searched lot in google but not getting proper answer. I think there should be simple solution to get it.
Below is one link on stackoverflow.com but I am not getting
https://unix.stackexchange.com/questions/123493/disable-daylight-saving-time-in-debian-linux
For example:
current time in Newyork is
date
Wed Mar 23 04:51:54 EDT 2016
As per DST-free timezone definitions provided which just define the GMT-offset, called Etc/GMT±X:
TZ=Etc/GMT-1 date
Wed Mar 23 10:13:09 GMT-1 2016
Whereas DST is 1 hour forward on March 23 i.e. it should be Wed, Mar 23, 2016, 4:13 AM
Please anyone provide help.
U.S. Eastern time is often represented by the time zone name "America/New_York" or "US/Eastern". Equivalently, there is the "Posix" time zone name "EST5EDT". The essential fact here is that this zone is nominally 5 hours off of UTC (or 4 hours when daylight saving time is in effect).
There are also some DST-free zone names of the form "UTC-4" and "UTC+5".
So if you say
export TZ="UTC+5"
date
You'll see the date in the equivalent of U.S. Eastern Standard Time, without a DST correction.
(This is essentially what the high-rated answer at https://unix.stackexchange.com/questions/123493/disable-daylight-saving-time-in-debian-linux was trying to tell you, I think.)
If you wanted to take an arbitrary time zone name and construct from it an equivalent DST-free zone name, that'd be pretty tricky.
I have a remote Linux computer, a raspberry pi, that snaps two pictures a minute and uploads them to a Linux server. The photos are named like this: SITE-03-22-16-091543.jpeg. With the filename being formatted like: Sitename-month-day-year-hourminutesecond.jepg. Before the photo is sent, via scp, I embed some local weather date into each photo using exiv2. That way the weather conditions are stored within each photo. All of that is working fine. I hope to have about 15 of these all sending back two snaps a minute to the server.
On the server side, these photos are stored within their own SITE folder. The idea is to make time-lapse videos from each site. There are four types of time-lapses we are interested in:
1) A 24 hour loop, from 12:00am to 11:59pm.
2) A sunrise loop, from 30 minutes before sunrise to 2 hours past sunrise
3) A sunset loop, from 2 hours before sun set to 30 minutes past sunset
4) A daylight loop, from 30 minutes before sunrise to 30 minutes past sunset
The 24 hour loop is simple.
The sunrise and sunset loops are a little trickier. I downloaded and complied the “sunwait” program from Ian Craig on SourceForge (https://sourceforge.net/projects/sunwait4windows/). Using the command “sunwait list rise 35.1174N 89.9711W | gawk -F: '{ print $1$2 }'” produces the output 0700, sun rise at my location. And using the 'set' option, produces 1913, sunset at my location. Since I don't live at the equator, the sunrise and sunset vary from 5:30am to 7:30am. Depending on season. Of course.
I have the code to compile a list of images into the move, add on overlay, and add the embedded weather data. The question is how to create a list of the 30 minutes of pictures before the sunrise + 2 hours. Then 2 hours before sunset + 30 minutes past. Then finally, 30 minutes before sunrise all the way through sunset + 30 minutes.
I'm sure the answer is MATH! Can someone start me on the yellow brick road?
awk to the rescue!
substituting your script to generate time by echo here
$ echo 07:10 |
awk -F: -v offset=30 -v path="$filepath" '{
h=$1-int(offset/60);
m=$2-offset%60;
if(m<0) {m=m+60; h--}
for(i=0;i<=150;i++)
{m++;
if(m>59) {m=m%60; h++};
printf path"%02d%02d.jpeg\n",h,m}}'
creates a 151 step counter that starts from offset (in minutes) given hours minutes. For the other case enter offset as 120. Assumes start/end times doesn't change the date. May not be true around North Pole!
I think some of the variables can be simplified, but can be a working base for further improvements.
update: int() was missing, fixed, also you can pass the path as another variable
If I define a specific time, how to get other local's time?
I use node.js and I know module (date-utils, moment-timezone). I will use some parameters (e.g. year, month, day, hour, minutes) and I want to get other country's time.
For example my server's local is America and I use a parameter (not real time specific time I want, and its my local's time) to server.
If I want to get Korean local time, what should I do?
If I want Korean's time 2015 07 07 11 11 and I will have 2015 07 07 11 11
how to get the Korean time from server?
I have a situation where the relative time is more important to a user than an absolute time. So it's more important to be able to quickly say "event happened 5 days and 5 hours ago" than "event happened at 1 PM CDT and it's 5 PM CST 5 days later now."
We store our dates in UTC and convert to display for the user:
pDateTime = DateTime.SpecifyKind(pDateTime, DateTimeKind.Utc);
DateTimeZone dateTimeZone = DateTimeZoneProviders.Tzdb[pCurrentUser.PreferredTimezone];
return Instant.FromDateTimeUtc(pDateTime).InZone(dateTimeZone).ToString("HH':'mm':'ss' 'MM'/'dd'/'yy' 'x", CultureInfo.InvariantCulture);
We'll be using NodaTime 1.2 when it's fully out and just used vanilla ToString before.
However, times using this pattern end up using the daylight status of the time as opposed to the current daylight status. This means that times look something like: 16:15:32 10/25/13 CDT even though we have now transitioned to CST.
It is an absolute measure of the time. This forces the user to do the logic: "How long ago was that? Is it daylight saving time now? If so, the difference is x. If not, I have to add or subtract an hour? That makes the difference y."
Meanwhile, a relative measure of the time would display 15:15:32 10/25/13 CST in the absence of DST. This forces the user to do no conversions and allows them to compute what that time means in context much easier.
In a display that has numerous dates, it can get tricky to do the absolute time logic over the entire set. Doing it once is tricky to get right. However, a friendly relative string like "posted 5 hours ago" also forces them to resolve both the date and time themselves - that information is still important.
A compromise might be to do the posted blank hours/minutes ago for the first 24 hours or to include both the friendly string and absolute time - these are both patterns I've seen done.
But ignoring those, is there a way in NodaTime to imbue a time with a specific daylight status in order to get times displaying in a relative context?
However, times using this pattern end up using the daylight status of the time as opposed to the current daylight status. This means that times look something like: 16:15:32 10/25/13 CDT even though we have now transitioned to CST.
Yes, and it should. Displaying a date/time with CST despite that date/time occurring in CDT would be very odd, IMO.
So it's more important to be able to quickly say "event happened 5 days and 5 hours ago" than "event happened at 1 PM CDT and it's 5 PM CST 5 days later now."
In that case you shouldn't be displaying a date/time at all, in my view. Convert both ZonedDateTime values to Instant, take the Duration between them, and then you can see that it's 5 days and 5 hours ago. (I can't remember how much help we provide with that - you may need to manually take the number of ticks and divide by NodaConstants.TicksPerStandardDay etc. Look at DurationPattern to see if it helps though.)
Alternatively, if you really want to display a date and time, but still easily be able to extract the difference between them mentally, two options suggest themselves:
Use OffsetDateTime instead; there you could force the offsets to be the same, although I still think it would be odd to display an offset which wasn't actually the current offset in the zone you were observing the time in. Or you could just display the relevant offset at the time, so -5 for CST and -4 for CDT.
Just display everything in UTC, so that daylight saving transitions are irrelevant.
Note that you can't get months between the two ZonedDateTime values, as we're dealing with an elapsed time (a duration) rather than calendar-logical arithmetic (a period).