Microsoft, Javascript and not cutting corners
-
SyntaxError: missing ) after formal parametersYou'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
my bad, haha, corrected!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
my bad, haha, corrected!
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Quote:
function ii(i: number, len?: number) {
You've corrected the outer function, but not the inner one. :-D
"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. :-D
"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! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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"
-
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.
-
At the risk of highlighting a horrible quick-n-dirty workaround I wrote a few months back, has anyone else come across this? I have some Javascript code that creates a date object, appends it to a URL, and does a GET to another page. At the server my (.Net) code then parses the date, but does some horrible clunky stuff to convert what Javascript has created into something .Net can parse. It does this by stripping off any reference to "GMT +0000 (GMT Standard Time)". The dates that Javascript formats when simply appending a date object a string are in the format
ddd MMM dd yyyy hh:MM:ss GMT+nnnn (xxxxxxx)
for instance
Fri Mar 24 2017 00:00:00 GMT+0000 (GMT Standard Time)
(BTW, this is an intranet app that ONLY runs on Chrome). All worked well in testing. All worked well in live... until the user started entering dates after March 26th, when .Net was parsing the date as "01-01-0001". Debugging on my system revealed the problem was the shift to daylight saving (British Summer Time); so I (stupidly, as I suspected at the time!) changed the server-side code to also strip off any text "GMT +0100 (GMT Summer Time)" which is what my browser was sending. I tested, all was well, put code live. Unfortunately this didn't resolve the problem for the user, and further investigation showed that, although they were on an identical version of Chrome, their system was sending "GMT +0100 (GMT Daylight Time)"; i.e. "Daylight Time" not "Summer Time". Further investigation showed that the only difference between development and live was that their systems were running Windows 7 Pro, whereas my development system was on Windows 8. So, Microsoft, what on earth possessed you to change the name of the time zone between one version of Windows and another?? So much for forward compatibility... :( :doh: :sigh: And yes, I am very much aware I should not be hard-coding timezone strings, even if this is an intranet app running in my own timezone... :cool:
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
-
At the risk of highlighting a horrible quick-n-dirty workaround I wrote a few months back, has anyone else come across this? I have some Javascript code that creates a date object, appends it to a URL, and does a GET to another page. At the server my (.Net) code then parses the date, but does some horrible clunky stuff to convert what Javascript has created into something .Net can parse. It does this by stripping off any reference to "GMT +0000 (GMT Standard Time)". The dates that Javascript formats when simply appending a date object a string are in the format
ddd MMM dd yyyy hh:MM:ss GMT+nnnn (xxxxxxx)
for instance
Fri Mar 24 2017 00:00:00 GMT+0000 (GMT Standard Time)
(BTW, this is an intranet app that ONLY runs on Chrome). All worked well in testing. All worked well in live... until the user started entering dates after March 26th, when .Net was parsing the date as "01-01-0001". Debugging on my system revealed the problem was the shift to daylight saving (British Summer Time); so I (stupidly, as I suspected at the time!) changed the server-side code to also strip off any text "GMT +0100 (GMT Summer Time)" which is what my browser was sending. I tested, all was well, put code live. Unfortunately this didn't resolve the problem for the user, and further investigation showed that, although they were on an identical version of Chrome, their system was sending "GMT +0100 (GMT Daylight Time)"; i.e. "Daylight Time" not "Summer Time". Further investigation showed that the only difference between development and live was that their systems were running Windows 7 Pro, whereas my development system was on Windows 8. So, Microsoft, what on earth possessed you to change the name of the time zone between one version of Windows and another?? So much for forward compatibility... :( :doh: :sigh: And yes, I am very much aware I should not be hard-coding timezone strings, even if this is an intranet app running in my own timezone... :cool:
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.
-
At the risk of highlighting a horrible quick-n-dirty workaround I wrote a few months back, has anyone else come across this? I have some Javascript code that creates a date object, appends it to a URL, and does a GET to another page. At the server my (.Net) code then parses the date, but does some horrible clunky stuff to convert what Javascript has created into something .Net can parse. It does this by stripping off any reference to "GMT +0000 (GMT Standard Time)". The dates that Javascript formats when simply appending a date object a string are in the format
ddd MMM dd yyyy hh:MM:ss GMT+nnnn (xxxxxxx)
for instance
Fri Mar 24 2017 00:00:00 GMT+0000 (GMT Standard Time)
(BTW, this is an intranet app that ONLY runs on Chrome). All worked well in testing. All worked well in live... until the user started entering dates after March 26th, when .Net was parsing the date as "01-01-0001". Debugging on my system revealed the problem was the shift to daylight saving (British Summer Time); so I (stupidly, as I suspected at the time!) changed the server-side code to also strip off any text "GMT +0100 (GMT Summer Time)" which is what my browser was sending. I tested, all was well, put code live. Unfortunately this didn't resolve the problem for the user, and further investigation showed that, although they were on an identical version of Chrome, their system was sending "GMT +0100 (GMT Daylight Time)"; i.e. "Daylight Time" not "Summer Time". Further investigation showed that the only difference between development and live was that their systems were running Windows 7 Pro, whereas my development system was on Windows 8. So, Microsoft, what on earth possessed you to change the name of the time zone between one version of Windows and another?? So much for forward compatibility... :( :doh: :sigh: And yes, I am very much aware I should not be hard-coding timezone strings, even if this is an intranet app running in my own timezone... :cool:
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.
-
At the risk of highlighting a horrible quick-n-dirty workaround I wrote a few months back, has anyone else come across this? I have some Javascript code that creates a date object, appends it to a URL, and does a GET to another page. At the server my (.Net) code then parses the date, but does some horrible clunky stuff to convert what Javascript has created into something .Net can parse. It does this by stripping off any reference to "GMT +0000 (GMT Standard Time)". The dates that Javascript formats when simply appending a date object a string are in the format
ddd MMM dd yyyy hh:MM:ss GMT+nnnn (xxxxxxx)
for instance
Fri Mar 24 2017 00:00:00 GMT+0000 (GMT Standard Time)
(BTW, this is an intranet app that ONLY runs on Chrome). All worked well in testing. All worked well in live... until the user started entering dates after March 26th, when .Net was parsing the date as "01-01-0001". Debugging on my system revealed the problem was the shift to daylight saving (British Summer Time); so I (stupidly, as I suspected at the time!) changed the server-side code to also strip off any text "GMT +0100 (GMT Summer Time)" which is what my browser was sending. I tested, all was well, put code live. Unfortunately this didn't resolve the problem for the user, and further investigation showed that, although they were on an identical version of Chrome, their system was sending "GMT +0100 (GMT Daylight Time)"; i.e. "Daylight Time" not "Summer Time". Further investigation showed that the only difference between development and live was that their systems were running Windows 7 Pro, whereas my development system was on Windows 8. So, Microsoft, what on earth possessed you to change the name of the time zone between one version of Windows and another?? So much for forward compatibility... :( :doh: :sigh: And yes, I am very much aware I should not be hard-coding timezone strings, even if this is an intranet app running in my own timezone... :cool:
There is a standard date/time format when interchanging information between different applications: [ISO 8601](https://en.wikipedia.org/wiki/ISO\_8601)
string data = "2017-04-14T01:27:00+02";
DateTime dt = DateTime.Parse(data); -
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.
