I currently use a Receiver class which receives my Midi Events from my Midi keyboard.
With each event the send() method returns some information along with the timestamp of the MidiEvent.
When I create a Calendar instance and getTimeInMillis() I get a completely different number to the Receiver's timestamp. The difference of the two values change every time, so I know it's not just a constant value.
Is there a way to get the Receiver's timestamp value at any time without it being through the Receiver's send() method?
By this I mean get a timestamp in a method which follows the same time scale as the Receiver's timestamp.
I believe you may be operating under a misconception - the value of the timestamp Receiver.send() expects is in microseconds, not milliseconds like in Calendar. That means you're off by a factor of 1000, which would appear to be a 'constantly changing value'.
I don't know whether you want to just reduce the resolution of your timestamps, or use the microseconds. It would depend on the exact nature of your application, what data you're getting in your messages, and what you want to do with them.
EDIT:
This is based on the assumption that you're receiving the data, not that you're populating the timestamp value.
If you need to preserve the resolution, here are some options:
Use the java.sql.Timestamp subclass of Date. This can store resolutions down to nanoseconds (more then what you need). However, all of the standard date utilities in the library have some odd behaviour, and the namespace is perhaps less than ideal.
Write your own JRE/JDK/JVM. Calendar and Date are part of the standard library. If you want to distribute your code, you have to expect people to use your version of the standard library. This is inadvisable, for a large number of reasons.
Find/Write your own timestamp-type class. There are probably audio libraries that have a relevant implementation. If you do have to write your own, I'd probably grab the code from Joda Time, and just change the resolution - that would still be a fair bit of work, though.
Just leave the value as the primitive. It's unlikely you need anything more than the numeric values, after all (not like you need to translate to year-month-day values). Although it would be good to have type safety for this, especially in light of the resolution differences. If this doesn't match your use case, I'm sorry.
Related
I'm running a pipeline, source from Kafka topic and sink to an IMap. Everytime I write one, I come across the methods withIngestionTimestamps() and withoutTimestamps() and wondering how are they useful? I understand its all about the source adding time to the event. Question is how do I get to use it? I don't see any method to fetch the timestamp from the event?
My IMap have a possibility of getting filled with duplicate values. If I could make use of the withIngestionTimestamps() method to evaluate latest record and discard the old?
Jet uses the event timestamps to correctly apply windowing. It must decide which event belongs to which window and when the time has come to close a window and emit its aggregated result. The timestamps are present on the events as metadata and aren't exposed to the user.
However, if you want to apply your logic that refers to the wall-clock time, you can always call System.currentTimeMillis() to check it against the timestamp explicitly stored in the IMap value. That would be equivalent to using the processing time, which is quite similar to the ingestion time that Jet applies. Ingestion time is simply the processing time valid at the source vertex of the pipeline, so applying processing time at the sink vertex is just slightly different from that, and has the same practical properties.
Jet manages the event timestamp behind the scenes, it's visible only to processors. For example, the window aggregation will use the timestamp.
If you want to see the timestamp in the code, you have to include it in your item type. You have to go without timestamps from the source, add the ingestion timestamp using a map operator and let Jet know about it:
Pipeline p = Pipeline.create();
p.drawFrom(KafkaSources.kafka(...))
.withoutTimestamps()
.map(t -> tuple2(System.currentTimeMillis(), t))
.addTimestamps(Tuple2::f0, 2000)
.drainTo(Sinks.logger());
I used allowedLag of 2000ms. The reason for this is that the timestamps will be added in a vertex downstream of the vertex that assigned them. Stream merging can take place there and internal skew needs to be accounted for. For example it should account for the longest expected GC pause or network delay. See the note in addTimestamps method.
I'm writing a toy logistics service. As a result, products will travel through lots of different timezones, and I'll need to query both the strict ordering of events, as well as what hour of day it is for products (for example, what happened when the sun was at its hottest, at 1200).
At the moment, I'm saving jodatime DateTimes and trying to deal with them exclusively, but I know time is mighty tricky, and I'm wondering if I need to do anything else to make sure it all works.
Given that you're recording events as they occur (rather than planning for future events), you probably don't need to worry about changes to time zone rules which occur in the future.
As such, it would be reasonable to store a timestamp (e.g. as UTC) and also the time zone ID for the location of the event. To make querying easier, you could also store the local time at the time of the event. Just be aware that as a toy is travelling through time zones, there could be multiple events at different instants in time, all of which occur at "midday" on the same day (but in different zones). You really need to think carefully about what queries you really want to perform on the local date/time values.
I am not familiar with jodatime but when I need to store the time I always enjoy using Epoch time because it is very easy to manipulate to get different formats. If you're interested in it here is a converter website that I find very helpful: http://www.epochconverter.com/
I am trying to conduct some extremely accurate data measurements. For this, I need to be able to get the current time in microseconds, accurate to 100 microseconds (Or more). I can't seem to be able to find any way on the Android Developer website. Device specific answers are acceptable (I have access to a Nexus 7, so any answers involving that would be awesome).
I had originally thought it possible to use the system sensors which give times accurate to the microsecond, however I have no idea how to set and/or tell if the sensors are accurate. Not to mention whether these event. - SensorManager
Is there any way to get the time in microseconds on an android device that is accurate to within 100microseconds?
you can use System.nanoTime(). according to doc
Returns the current timestamp of the most precise timer available on
the local system. This timestamp can only be used to measure an
elapsed period by comparing it against another timestamp. It cannot be
used as a very exact system time expression.
Returns
the current timestamp in nanoseconds.
From the java doc here you will get some extra explanation of it
Trying to get a time stored in a datadase.
select dbtimezone from dual gives me -07:00
I am using Java program to get the Date from Oracle
Column i type of Date.
while i am fetching the time in my java program am getting it as GMT.
actually i want the time as it is there in database not converted time.
Though i can convert back to -07:00 , i am seeking another way to do because conversion always depends on the dbtimezone of the database using.
Can any one help me ?
Thanks in advance
That oracle just has one timezone can make life difficult if you deal with different timezones. I've always thought life was easier if you consider timezone a view artifact and
represent all times as UTC, then convert in the view. You put the timezone information someplace in the database and convert accordingly.
...actually getting that right can get interesting because you don't want to make the same mistake of being too general again. For example, a client may be based in a particular timezone, but have offices in many. Though an office is in a particular timezone, the activity relating to the time may involve a different timezone etc.
See java.util.TimeZone, more specifically the getOffset methods, which return the number of milliseconds to add to the UTC time to get local time. Note that it also considers the daylight saving time.
I need to add timezone information to a db table with user maintained locations. The data will be accessed mostly from Java code but there is also some PL/SQL and Win32 (Delphi) code which needs to understand the timezone information.
It seems straight forward to use the id from java.util.TimeZone. Java can easily convert that (obviously), Hibernate has built-in support for it and apparently also Oracle understands those timezone ids:
select TZ_OFFSET('Pacific/Marquesas') from dual.
The problem is: the timezone ids do not seem to be compatible with the Windows Timezone DB. For example, the java.util.timezone id "Pacific/Marquesas" (-09:30) is not in the timezone picklist in Windows. The registry does not contain it at all; see
\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones
Here I can only pick either -09:00 or -10:00. So, if I were to store the timezone like this, how can I get to the actual offset/DST infos in Windows (without Java)? Hopefully this does not require a mapping table which I have to keep up to date whenever it changes. Is there a globally accepted standard which works better than the java timezone id?
Update
The timezone info is used in combination with DATE columns on the database. Those columns contain local date/time values. If a location can be associated with those values, the location's timezone enables me to convert the date/time value to UTC or any other timezone whenever needed.
I realize that instead of DATE a TIMESTAMP_TZ data type or something similar would be more appropriate. However, this would require a data migration (for which the TZ is required again) and is not supported by the legacy applications which also work on the data (unless a lot of code is changed). The problem is almost the same if I had to convert the values to UTC.
Bottom line is I need to keep the DATE values in local time but I need to know for some of them which TZ that means.
I can give a little background, if not a real answer.
Many systems use the Olson implementation of timezone data. So those names work in many systems (most Unix, Java, Oracle I think). Microsoft does their own thing.
I see at the bottom of that Wikipedia link there's a reference to some mapping to the Windows world.
Good luck!
I realize this is not the best way to do it, but it might be sufficient in your case. Without knowing all the requirements I can't tell.
What do you need to use the time zone information for? Just to present the time with the correct offset and maybe also the name of the time zone?
You could continue to use Java to determine what the offset of the user is by looking up the user's selected time zone using Java. Each time the user logs in record in your database what the offset currently is. Then other apps can look at this information to determine how to format the time.
This assumes that users who regularly login are the ones that this needs to be done for. If that's not the case you could run a daily job to lookup the time zone for each user in Java and record the offset currently in effect.
Hackish, agreed, but the only other way I see is to maintain a mapping. And what happens when someone selects a time zone that you don't have a mapping for?