Microsoft, Javascript and not cutting corners
-
:sigh: So it was just a brief aberration by MS then, to change the display name of the timezone from "GMT Daylight Time" to "GMT Summer Time". Thus screwing up not only forward compatibility, but backwards compatibility too. I love this job. :(( (And yes, to all other posters who've showed a way around, I understand... I really am just highlighting an issue with MS's naming of time zones!)
Aah, one of our customers had exactly this problem on their Windows 2012 servers - some were showing "GMT Daylight" Time, others "GMT Summer Time", even though they had all been built "exactly the same" (by a third party). It's a region/locale difference, one is English (US), the other is English (United Kingdom). I think it comes from the tzres.dll.
-
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).
-
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).
-
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:
If you don't care about local time zone information, just send the absolute numeric time: Date.getTime(); https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global\_Objects/Date/getTime Worse case, you might have to apply some fixed adjustment if your server Date/Time code works off of a different time 0 value.
-
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:
You should also be very much aware to never trust JavaScript mixed type string concatenation.
Immanentize the Eschaton!
-
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:
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.
-
Typescript to the rescue, format your date on the client side!!
interface Date {
format(pattern: string, utc?: boolean): string;
}
// http://stackoverflow.com/questions/14638018/current-time-formatting-with-javascript
Date.prototype.format = function (pattern: string, utc?: boolean) {
var MMMM = ["\x00", "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
var MMM = ["\x01", "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"];
var dddd = ["\x02", "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"];
var ddd = ["\x03", "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"];function ii(i: number, len?: number) { var s = i + ""; len = len || 2; while (s.length < len) s = "0" + s; return s; } var y = utc ? this.getUTCFullYear() : this.getFullYear(); pattern = pattern.replace(/(^|\[^\\\\\])yyyy+/g, "$1" + y); pattern = pattern.replace(/(^|\[^\\\\\])yy/g, "$1" + y.toString().substr(2, 2)); pattern = pattern.replace(/(^|\[^\\\\\])y/g, "$1" + y); var M = (utc ? this.getUTCMonth() : this.getMonth()) + 1; pattern = pattern.replace(/(^|\[^\\\\\])MMMM+/g, "$1" + MMMM\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])MMM/g, "$1" + MMM\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])MM/g, "$1" + ii(M)); pattern = pattern.replace(/(^|\[^\\\\\])M/g, "$1" + M); var d = utc ? this.getUTCDate() : this.getDate(); pattern = pattern.replace(/(^|\[^\\\\\])dddd+/g, "$1" + dddd\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])ddd/g, "$1" + ddd\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])dd/g, "$1" + ii(d)); pattern = pattern.replace(/(^|\[^\\\\\])d/g, "$1" + d); var H = utc ? this.getUTCHours() : this.getHours(); pattern = pattern.replace(/(^|\[^\\\\\])HH+/g, "$1" + ii(H)); pattern = pattern.replace(/(^|\[^\\\\\])H/g, "$1" + H); var h = H > 12 ? H - 12 : H == 0 ? 12 : H; pattern = pattern.replace(/(^|\[^\\\\\])hh+/g, "$1" + ii(h)); pattern = pattern.replace(/(^|\[^\\\\\])h/g, "$1" + h); var m = utc ? this.getUTCMinutes() : this.getMinutes(); pattern = pattern.replace(/(^|\[^\\\\\])mm+/g, "$1" + ii(m)); pattern = pattern.replace(/(^|\[^\\\\\])m/g, "$1" + m); var s = utc ? this.getUTCSeconds() : this.getSeconds(); pattern = pattern.replace(/(^|\[^\\\\\])ss+/g, "$1" + ii(s)); pattern = pattern.replace(/(^|\[^\\\\\])s/g, "$1" + s); var f = utc ? this.getU
HOLY GEEZUS! I like TypeScript and all but what What WHAT?! Shouldn't This Be Easier(TM)
-
HOLY GEEZUS! I like TypeScript and all but what What WHAT?! Shouldn't This Be Easier(TM)
holymolly.. only 3 top line are typescript specific.. the rest is plain old javascript format function! ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
HOLY GEEZUS! I like TypeScript and all but what What WHAT?! Shouldn't This Be Easier(TM)
Don't worry, I made a javascript only version for ya! Much simplerer! ;)
// http://stackoverflow.com/questions/14638018/current-time-formatting-with-javascript
Date.prototype.format = function (pattern, utc) {
var MMMM = ["\x00", "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
var MMM = ["\x01", "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"];
var dddd = ["\x02", "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"];
var ddd = ["\x03", "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"];function ii(i, len) { var s = i + ""; len = len || 2; while (s.length < len) s = "0" + s; return s; } var y = utc ? this.getUTCFullYear() : this.getFullYear(); pattern = pattern.replace(/(^|\[^\\\\\])yyyy+/g, "$1" + y); pattern = pattern.replace(/(^|\[^\\\\\])yy/g, "$1" + y.toString().substr(2, 2)); pattern = pattern.replace(/(^|\[^\\\\\])y/g, "$1" + y); var M = (utc ? this.getUTCMonth() : this.getMonth()) + 1; pattern = pattern.replace(/(^|\[^\\\\\])MMMM+/g, "$1" + MMMM\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])MMM/g, "$1" + MMM\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])MM/g, "$1" + ii(M)); pattern = pattern.replace(/(^|\[^\\\\\])M/g, "$1" + M); var d = utc ? this.getUTCDate() : this.getDate(); pattern = pattern.replace(/(^|\[^\\\\\])dddd+/g, "$1" + dddd\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])ddd/g, "$1" + ddd\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])dd/g, "$1" + ii(d)); pattern = pattern.replace(/(^|\[^\\\\\])d/g, "$1" + d); var H = utc ? this.getUTCHours() : this.getHours(); pattern = pattern.replace(/(^|\[^\\\\\])HH+/g, "$1" + ii(H)); pattern = pattern.replace(/(^|\[^\\\\\])H/g, "$1" + H); var h = H > 12 ? H - 12 : H == 0 ? 12 : H; pattern = pattern.replace(/(^|\[^\\\\\])hh+/g, "$1" + ii(h)); pattern = pattern.replace(/(^|\[^\\\\\])h/g, "$1" + h); var m = utc ? this.getUTCMinutes() : this.getMinutes(); pattern = pattern.replace(/(^|\[^\\\\\])mm+/g, "$1" + ii(m)); pattern = pattern.replace(/(^|\[^\\\\\])m/g, "$1" + m); var s = utc ? this.getUTCSeconds() : this.getSeconds(); pattern = pattern.replace(/(^|\[^\\\\\])ss+/g, "$1" + ii(s)); pattern = pattern.replace(/(^|\[^\\\\\])s/g, "$1" + s); var f = utc ? this.getUTCMilliseconds() : this.getMilliseconds(); pattern = pattern.replace(/(^|\[^\\\\\])fff+/g
-
Don't worry, I made a javascript only version for ya! Much simplerer! ;)
// http://stackoverflow.com/questions/14638018/current-time-formatting-with-javascript
Date.prototype.format = function (pattern, utc) {
var MMMM = ["\x00", "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December"];
var MMM = ["\x01", "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"];
var dddd = ["\x02", "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday"];
var ddd = ["\x03", "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"];function ii(i, len) { var s = i + ""; len = len || 2; while (s.length < len) s = "0" + s; return s; } var y = utc ? this.getUTCFullYear() : this.getFullYear(); pattern = pattern.replace(/(^|\[^\\\\\])yyyy+/g, "$1" + y); pattern = pattern.replace(/(^|\[^\\\\\])yy/g, "$1" + y.toString().substr(2, 2)); pattern = pattern.replace(/(^|\[^\\\\\])y/g, "$1" + y); var M = (utc ? this.getUTCMonth() : this.getMonth()) + 1; pattern = pattern.replace(/(^|\[^\\\\\])MMMM+/g, "$1" + MMMM\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])MMM/g, "$1" + MMM\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])MM/g, "$1" + ii(M)); pattern = pattern.replace(/(^|\[^\\\\\])M/g, "$1" + M); var d = utc ? this.getUTCDate() : this.getDate(); pattern = pattern.replace(/(^|\[^\\\\\])dddd+/g, "$1" + dddd\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])ddd/g, "$1" + ddd\[0\]); pattern = pattern.replace(/(^|\[^\\\\\])dd/g, "$1" + ii(d)); pattern = pattern.replace(/(^|\[^\\\\\])d/g, "$1" + d); var H = utc ? this.getUTCHours() : this.getHours(); pattern = pattern.replace(/(^|\[^\\\\\])HH+/g, "$1" + ii(H)); pattern = pattern.replace(/(^|\[^\\\\\])H/g, "$1" + H); var h = H > 12 ? H - 12 : H == 0 ? 12 : H; pattern = pattern.replace(/(^|\[^\\\\\])hh+/g, "$1" + ii(h)); pattern = pattern.replace(/(^|\[^\\\\\])h/g, "$1" + h); var m = utc ? this.getUTCMinutes() : this.getMinutes(); pattern = pattern.replace(/(^|\[^\\\\\])mm+/g, "$1" + ii(m)); pattern = pattern.replace(/(^|\[^\\\\\])m/g, "$1" + m); var s = utc ? this.getUTCSeconds() : this.getSeconds(); pattern = pattern.replace(/(^|\[^\\\\\])ss+/g, "$1" + ii(s)); pattern = pattern.replace(/(^|\[^\\\\\])s/g, "$1" + s); var f = utc ? this.getUTCMilliseconds() : this.getMilliseconds(); pattern = pattern.replace(/(^|\[^\\\\\])fff+/g
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
-
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
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.