|
SyntaxError: missing ) after formal parameters
You've left the TypeScript parameter types in there.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
|
Quote:
function ii(i: number, len?: number) {
You've corrected the outer function, but not the inner one. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
damn you man, this is way too much attention to detail!
I am having a sleepless night watching movie now! 
|
|
|
|
|
Congratulations, your date is now "implementation-dependent" due to toString.
ECMA-262 wrote: 20.3.4.41.1 Runtime Semantics: ToDateString(tv)
The following steps are performed:
1. Assert: Type(tv) is Number.
2. If tv is NaN, return "Invalid Date".
3. Return an implementation-dependent String value that represents tv as a date and time in the current time
zone using a convenient, human-readable form.
Luckily there is a method toUTCString or a library "moment" to allow to explicitly say the format, since ECMA are more concerned by invariants (that almost no good javascript programmer have problem with) than dates (that almost everyone works with). 
|
|
|
|
|
There are two basic rules for passing datetime between systems:
- Use UTC.
- When passing as string use a fixed format and not one that depends on local system settings.
The recommended string format is according to ISO 8601 - Wikipedia[^].
|
|
|
|
|
I completely agree with using ISO 8601!
(but I kindly refer to a Stackoverflow answer that fixes the (in my opinion, wrong) JSON behaviour of serializing a js Date to a UTC string and losing all timezone information).
|
|
|
|
|
It all depends on the requirements.
If you need time zone information, you must pass it too of course. If you don't need the TZ name, using the offset is fine because that can be simply parsed. If you need the name do not use the full name but the abbreviation (see List of time zone abbreviations - Wikipedia[^]).
Handling local times is always a nightmare. For this reason there is the general rule to always use UTC. Only when dates should be displayed they might be converted to local time.
When having tabular data containing multiple records, use UTC for the records and store the time zone information in a single record (e.g. within the user record). This applies especially when the timestamps has to be stored in binary format (like with databases).
|
|
|
|
|
|
You should also be very much aware to never trust JavaScript mixed type string concatenation.
Immanentize the Eschaton!
|
|
|
|
|
So, you GENERATED the URL.
You used the complicated format of the date/time string given to you by default, and hard to test manually.
As opposed to formatting the date in Javascript to be: YYYYMMDD_HHNNSS and simply parsing that on the other end?
Try to make your code immutable to the version of windows, etc.
|
|
|
|
|
Yes, I said I was being lazy. Yes, I know I did it a foolish way. The ONLY point of my post in Weird and Wonderful was to highlight a weird and wonderful (and undocumented, it would seem) change in the Time Zone description by Microsoft from "Daylight Time" to "Summer Time" with Win8 (and, it would seem, back to "Daylight Time" in Win10).
"This forum is purely for amusement"
|
|
|
|
|
I get the point of the post. But I want to make sure YOU and even OTHERS realize that the solution is to really work to insulate yourself from these things from the jump.
In fact, I just "auto saved" a file in my program, and I forced the YYYYMMDD_HHNNSS format to the prefix, so it is sortable, and gives a clue as to when it was made, how old, etc.
|
|
|
|
|
Why are you screwing around with strings?
In Javascript "Date.now()" returns the number of milliseconds since 1/1/1970 (GMT). Pass that number in the URL.
On the server-side:
new DateTime(1970,1,1) + new TimeSpan(now * 1000)
Give you the date/time.
Truth,
James
|
|
|
|
|
Ah! Many happy memories of hair tearing and cat kicking. So many variables and none of them nice.
My best suggestion is to convert all dates into standard strings using the inbuilt date formatting functions. Whatever you do, don't pass dates as date objects. You will regret it...
We're philosophical about power outages here. A.C. come, A.C. go.
|
|
|
|
|
Quote: I have some Javascript code
That's where I stopped, already more horror than I can take, can't risk reading the continuation.
Be strong.
|
|
|
|
|
Ha ha! The issue was nothing to do with Javascript, rather Microsoft's random renaming of time zones.
|
|
|
|
|
There is a standard date/time format when interchanging information between different applications:
ISO 8601
string data = "2017-04-14T01:27:00+02";
DateTime dt = DateTime.Parse(data);
|
|
|
|
|
|
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
I think this should be moved to the soapbox
|
|
|
|
|
True but it has so little traction that who cares?
|
|
|
|
|
I do. Those with integtity do.
|
|
|
|
|
dlhale wrote: integtity
I think you compromised the integrity of your sentence 
|
|
|
|
|
Typing on an IPad leaves much to be desired, and many typos.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
