This may be a strange question, but I'm using a Decimal to store a timestamp with more than millisecond precision. For example:
The time of 00:01:15, would be 75 seconds / 216000 seconds in a day = 0.00034722222.
The date of "2014-01-01 ==> 41638 (days since 1900-01-01)
The datetime of "2014-01-01 00:01:15.12222" would be 41638.00034778805.
Is there any possible way at all to include the timezone (such as "-6") in this data type? I think the answer is no, but I was wondering if there might be any tricks to be able to store that amount in the decimal.
I don't think it's possible, and perhaps I'll need to use either a String or an Array of [<datetime>, <timezone>] to get past Javascript's millisecond precision (using a library such as Decimal.js for high precision decimals), but I was wondering what might be possible here.
The reason I'm using a decimal here to be able to store a time or date in a similar format and to be able to add them together for certain operations (such as how Excel or Google Sheets would store dates/times, as a number). But timezone complicates things quite a bit here.
Related
Does it matter how big numbers to calculate in JavaScript Engine, especially V8 in NodeJS?
The applicable example: I'm calculating in loops time date variables in milliseconds and have some time variables in minutes. I have doubts should I convert all times from minutes to milliseconds to have everything consistent, or vice-versa to have smaller values for easer calculation?
time in minutes: 27686190
time in milliseconds: 1661171400000
Converting complexity from milliseconds to minutes (I believe insignificant) - 2 variables per loop. From minutes to milliseconds - 2 variables once.
Apart from BigInt, all JS math is done on 64-bit floating point numbers1. All operations have constant time complexity, they do not depend on the values they are working with.
Either way, start by writing clear, idiomatic and correct code. It will be optimised well enough by the engine. Only when you identify a performance bottleneck in a particular part of the code, and think you can outsmart the engine optimisations, benchmark your different approaches.
1: Some engines, V8 in particular, optimise storage and computation for small integers (like most array indices). Operations on them might be faster than a floating-point operation, but still they have constant time complexity and do not depend on which integers they work with.
I've got a problem with timestamps between java and javascript.
I already found these 2 questions about the timestamps and I know about the timechanges all over the years.
Timestamp deviation Java vs Javascript for old dates (3600secs)
Why is subtracting these two times (in 1927) giving a strange result?
Basically at midnight at the end of 1927, the clocks went back 5
minutes and 52 seconds. So "1927-12-31 23:54:08" actually happened
twice, and it looks like Java is parsing it as the later possible
instant for that local date/time.
What the problems makes is that when I have javascript and put the timestamp in there then I get an other date than the Java date. I need this to show the correct date on the webpage. I know I can request the date as a string but I prefer using a timestamp.
Java date 0001-01-01 timestamp is -62135773200000
JavaScript date 0001-01-01 timestamp is -62135596800000
The difference is -176400000; 49 hours.
Does anybody know what I can do for this.
Personally, I would avoid passing numerical timestamps around from a system in one language to a system in another language for the sole reason that the languages may differ in the algorithm they use to generate them.
There is an international standard in place (ISO-8601) to deal with passing timestamps from system to system. In this your date representation becomes 0001-01-01T00:00:00+00:00. I would recommend using this approach, as it's a widely accepted solution for this very problem.
This might be related to TZ and DST settings which diverge from browser to java. In order to nail it down, I recommend to use ISO-8601 formats like 2008-02-01T09:00:22+05, this is ambiguous-less
I have seen and read a number of comments regarding calculating the days between dates, as it relates to JS. My question is-I need to calculate this information in Adobe LiveCycle Designer. I have the two fields I need to reference in the script. The first is the static field with the last known date of an event, the second is the current date/time (which is entered by the end user). I need to know how to write the script to find the difference between these two fields, with the calculation resulting in days. I do not need to be exact, daylight savings time, leap year, time zones etc. are not important. Just need to get to an integer. Thanks in advance for the help.
The quick and dirty way to do it involves an epoch subtraction. In Javascript, the date epoch is available from Date.getTime(); as seen on W3 Schools. If you're looking for a more robust approach and if you have a need for additional date and time operation, I would suggest looking into Moment.js. Moment.js is technically a JavaScript library aimed at browsers, etc. but it can be wrapped in a Script Object to be used in an XFA form.
I need a way to serialize and unserialize dates that are potentially far away in the past, for instance -10000
I first look at ISO8601, but it does not seem to support years with more than four digits. (Or at least, python libraries I tried don't.)
The different solutions I can think of:
change the year before serializing/deserializing, give it to the parsing/formatting library, and fix it back (sounds hacky)
define my own format, like year:month:day:hour:minute:second (that is reinventing the wheel, since I have to handle timezones, etc.)
Use a UNIX timestamp without bounds or something equivalent (may overflow in some programming languages, and still the timezone stuff)
Store dates before -9999 (or 0) differently than those after, since there was no timezone issue/leap years/… issue at that time. (two different formats at the same place)
Do you see any other way that would be better than these ones? Or recommand one of those?
You could take a page from the astronomy people. Sky maps they account for long period precession of Earth's spin by establishing epochs. (The sky is different if you're looking now vs 10,000 BC.)
Create a new class that has an "epoch" number and a facade pattern of your current date class. The new class contains two private fields for epoch and internal-date. Your constructor sets epoch to (year div 10000), and instantiates the internal-date with (year modulo 10000). I hope rest of the facade pattern is as obvious as I think.
ISO 8601 does support dates with more than 4 digits if, and only if, they are signed. The only PHP function I know of that supports this functionality is
DateTime::setISODate($Year, $WeekOffset, $DayofWeekOffset)
Obviously it's a pain to use because it requires calculating the offsets from perfectly good day/month pairs. That said, you should be able to create BC dates by signing the year with a '-'(minus sign).
Then you'd output the date with
DateTime::format("c")
In production this would look something like:
$date= new DateTime();
$date->setISODate(-100000,$WeekOffset, $DoWOs);
echo $date->format("c");
Take a look at FlexiDate class — it might be useful for you purposes.
It is not a standards-compliance way in any way, but it might do the trick for you
Is there an accepted way to represent high resolution timestamps in JSON and/or JavaScript?
Ideally, I would like it to support at least 100 ns resolution, since that would make the server code a bit simpler (since the .NET DateTime resolution is 100 ns as well).
I found a lot of questions dealing with manipulating high-resolution timers and such (which is not possible, apparently), but I simply need to represent it somehow, in an application API.
This is for an API built in REST style using JSON, so actually measuring time in this resolution is not required. However, I would like to transfer and use (potentially in JavaScript) the timestamp in its full resolution (100 ns, since this is .NET).
In light of your clarification, isn't your timestamp just a really big integer? The current timestamp is 1329826212. If you want nanosecond precision, we are just talking about like 9 more digits: 1329826212000000000. That is a number that JavaScript can easily handle. Just send it over as:
myobject = {
"time": 1329826212000000000
}
It should be perfectly fine. I just tried doing some arithmetic operations on it, division by a large number and multiplication by the same. There is no loss of value.
JavaScript supports a huge range of floating point numbers, but guarantees integral accuracy from -2^53 to 2^53. So I think you are good to go.
UPDATE
I'm sorry, I just re-read your question. You wish to represent it? Well, one thing I can think of is to extract the last 9 digits (additional precision beyond second granularity) and show them to be the decimal part of the number. You may even wish to extract the last 6 digis (additional precision beyond the millisecond granularity).
The JavaScript Date object only has millisecond precision.
However, if you are just looking for a standard format to encode nanosecond precision times, an ISO 8601 format string will allow you to define nanoseconds as fractions of seconds:
Decimal fractions may also be added to any of the three time elements. A decimal point, either a comma or a dot (without any preference as stated most recently in resolution 10 of the 22nd General Conference CGPM in 2003), is used as a separator between the time element and its fraction. A fraction may only be added to the lowest order time element in the representation. To denote "14 hours, 30 and one half minutes", do not include a seconds figure. Represent it as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties.
There is a trick used by jsperf.com and benchmarkjs.com that uses a small Java applet that exposes Java's nanosecond timer.
See Stack Overflow question Is there any way to get current time in nanoseconds using JavaScript?.