Storing dates with more-than-4-digits years - javascript

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

Related

How does JavaScript represent strings and Date objects in memory?

How does JavaScript represent strings and Date objects in memory?
Context and Intent
I'm mostly just curious, but here's what led to the question: We have code in our React front end that accepts JSON payloads from our API, and those payloads include dates -- in ISO-8601 UTC string form (e.g. 2023-02-01T17:01:08Z), of course.
As we pass the resulting model object around a variety of hooks, components, functions, etc., we keep it as a string, and we only parse it into a Date object if we are going to display it or use it to make decisions. In some cases, this means that we'll re-parse the same string into a Date multiple times in the course of rendering the UI. In other cases, we ignore the Date completely as it's not relevant for the page.
I'm trying to reason about whether it would be worthwhile to modify our system such that we always parse Date strings into actual Date objects upon receipt from our API. Our UI is written in TypeScript -- AFAIK this makes no difference with regard to my actual question -- and my biggest motivator in wanting to make this change is the improved type safety and clarity.
To be clear, time performance is the bigger concern, but I can do my own benchmarking. For the purposes of this question, I'm asking about memory performance, as much for my own understanding and education as for any technical decisions that might result, but I always try to understand the full scope of any tradeoff.
I imagine that this could be implementation dependent; if so, I'm most interested in the facts as they apply to modern versions of Google Chrome (with default configuration, if that matters), but happy to learn about other implementations as well.
Questions
If I take a 20-character ISO-8601 UTC string and parse it into a Date, how much memory would the resulting Date use? Does JavaScript work like Java, using an 8-byte "long" integer to store dates as milliseconds since the epoch? I found disappointingly little information about this in my searching; most of the results I found were actually about Java.
Also, how much memory does the string use? What's Javascript's internal string encoding? A quick Google indicates that it uses UTF-16 (and therefore 40 bytes for the 20-character date string)?
For both Date and String, are there any differences in applicable overhead? Are there optimizations that might apply to either Strings or Dates and affect the result (e.g. string interning -- which if I am understanding this correctly, JS does, but it would not apply to my use case since the value came from an API response)?

Java and JavaScript timestamps are not the same

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

Calculate days between dates in LiveCycle Designer

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.

Does momentjs have something similar to joda-time's localDate? If not, is it best to use .startOf?

In the joda-time library (and I assume Java 8's new time library), you can ignore times and time zones: https://www.joda.org/joda-time/apidocs/org/joda/time/LocalDate.html
I would prefer to avoid having times factor in in my small app. I just want the user to see their local date. Is there a momentjs equivalent to localdate? If not, would the best workaround be to use .startOf()? Thanks.
Edit: Just to be clear, this is not a formatting question.
"By default, moment parses and displays in local time.
If you want to parse or display a moment in UTC, you can use moment.utc()"
As explained here.
moment().format(); // 2013-02-04T10:35:24-08:00 (local date)
moment.utc().format(); // 2013-02-04T18:35:24+00:00 (UTC date)

How should a RESTful GET resource accept a date-time argument? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there a standard date/time format that can be passed on a URL?
What is a good way for a RESTful resource to accept a datetime object? Specifically, I'm not sure what is a good way to represent the date and time as a query argument in the URL.
I was thinking of doing something like this:
GET /Calls?start=YYYY-MM-DD_HH:MM:SS
I'm using Javascript/jQuery on the Client and Python on the back end, so ideally it would be a format that could easily be written in Javascript and read in Python.
Thanks!
Use the ISO 8601 standard to encode the time argument as a string. It's readable for humans and supported by tons of libraries across many languages.
I'd recommend against using Unix time. Your sysadmins will thank you when they're asked to crawl or parse your web server logs for API calls. Using ISO 8601 will avoid them having to build a secondary step into that process to convert the Unix time number into something that actual humans have to understand.
Most datetime libraries (definitely both Python and JS) follow the same formatting approach, namely format strings. I'd go with any one that just uses digits, and uses descending order of size, i.e. YYYYMMDDhhmmss.
The one other thing to consider before jumping into a format is whether you might need to parameterize by something more akin to a date range, and if including the seconds, minutes, hours, etc. might over-specify the request and make it hard for the client to locate the data they are looking for.
unix time... http://en.wikipedia.org/wiki/Unix_time
why not just YYYYMMDDHHMMSS ?
As long as both sides can follow this format, I don't see any problem

Categories