This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Date object doesn't zupport timezones many people want to support timezones in their javascript applications, for world clocks, appointments, corporate business calendars, etc. but the Date object doesn't support this. apparently browser vendors don't all support .toISOSTring(). .toISOSTring should support parameters such as a timezone, for conversion to timezones. ISO8601-2004 supports suffix timezones in the format as Z for GMT.UTC or +hhmm -hhmm +hh -hh for instance, in the extended years format in 15.9.1.15.1 in ecmascript 262 specification for javascript you see a Z on the end. I am proposing allowing these timezones in Date.prototype.parse(). there should also be .getTimeZone() and .setTimeZone(integerTimeZoneHHMMoffset) methods for the Date object. and because the extended format requires zero padding and there are no zero padding functions, I am suggesting the following zero padding function of mine. I still need to use this zeropad function in my own code in various forms, because various languages again don't have this function. I write for many languages. I hope to improve those too. function str_repeat(s,n) { var s2=""; for (var __i=1; __i <= n; __i++) { s2+=s; } return s2; } function zeropad(n, numdigits) {//requires: nothing. returns string. on failure, alert() var s=""; var i; if (null==n) { //alert("zeropad(): undefined n"); return ""; } if (null==numdigits) { //alert("zeropad(): undefined numdigits"); return ""; } var nstr = n.toString(); var nInt = parseInt(n); var nIntStr = nInt.toString(); var numdigitsInt = parseInt(numdigits); if (isNaN(nInt)) { //must be hexadecimal or something else //nIntStr = nstr; s=str_repeat('0',Math.max(nstr.length,numdigitsInt) - Math.min(nstr.length,numdigitsInt)); return s+nstr; } else { if (Math.abs(n) > Math.abs(nInt)) { //has digits past decimal point if ("-" == nstr.substring(0,1)) { //is negative if (nstr.length < numdigits) { s = str_repeat('0',numdigitsInt - (nstr.length+1)); } return "-" + s + nstr.substring(1,nstr.length); } else { if (nstr.length < numdigits) { s = str_repeat('0',numdigitsInt - (nstr.length+1)); } //is positive and has no + sign in front return s + nstr; } } else { //has no digits past decimal point if ("-" == nstr.substring(0,1)) { //and is negative if (numdigitsInt-nIntStr.length >= 1) { s = str_repeat('0',numdigitsInt - nIntStr.length); } return "-" + s + nIntStr.substring(1,nIntStr.length); } else { //and is positive if (numdigitsInt-nIntStr.length >= 1) { s = str_repeat('0',numdigitsInt - nIntStr.length); } return s + nIntStr; } } } }
I would also add that the Date.prototype.getUTC (append a time,as in Seconds, Month, FullYear, whatever) should also be available as Date.prototype.getTZ (append a time as shown previously), where one of the parameters is an integer timezone offset in the form +-hhmm where you have the choice of doing hhmm as timezoneoffset=hh*60+mm or timezoneoffset=hh*100+mm I would suggest the former. so this is also part of the proposal. I just realized this is also necessary for implementing time zone functionality. I think this could also affect Date.prototype.toJSON(key) in that a new optional parameter would be added, a timezone, if I am understanding this correctly. a correction to previous post, "apparently browser vendors don't all support .toISOSTring().": .toISOSTring() should be .toISOString(), it had a typo.
I am thinking that there could also be a timezone parameter in the Date Date.prototype.MakeDay() and Date.prototype.MakeTime() would need a new kind of timezone version maybe called Date.prototype.MakeTimeTZ(year, month[, date[, hours[, minutes[, seconds[,milliseconds[, tzHours[, [tzMinutes]]]]]]]) because timezone depends upon th date, and generates hours and minutes. there would need to be a Date.TZ(year, month[, date, [hours[, minutes[, seconds[, milliseconds[, tzHours[, [tzMinutes]]]]]]]) which returns a TimeClip. there would need to be a change to 15.9.3.1, the Date constructor, new Date(year, month, [date[, hours[, minutes[, seconds[, milliseconds[, tzHours[, [tzMinutes]]]]]]]) and 15.9.2.1, the Date constructor called as a function: Date([year[, month[, date[, hours[, minutes[, seconds[, milliseconds[, tzHours[, [tzMinutes]]]]]]]]]])
somehow the comment I just submitted which would have made this more functional got dropped somehow. Date should be fully timezone-aware and DST-aware. (Daylight Saving Time) currently, Date.prototype.getTimezoneOffset() only provides the difference in minutes between local time and UTC. I would like to see the following functionality also added, which would be helpful for making clocks, dealing with time and such: Date.prototype.SetTimezoneOffset(minutesOffset) which minutesOffset can be calculated as hours*60+minutes and returns nothing (or you can return the output of .getTimezoneOffset()) essentially it does the opposite of Date.prototype.getTimezoneOffset() I would have preferred this function and Date.prototype.getTimezoneOffset() actually set the timezone offset and not both the DST and timezone offset at the same time. if that were to change to be timezone-only, one of 2 things can happen: - change is made and existing code will break, and people will simply have to change their code. - no change is made and this function prototype simply does the opposite of the current .getTimezoneOffset(), as messy as that is. ...maybe we DO need this function in the way I didn't prefer (I only wanted the nice function name, because it fits so well working with timezones). Date.prototype.isDST() returns a Boolean indicating whether or not DST is in effect or not. Date.prototype.enableDST(enable) where enableDST is Boolean that enables DST. Date.prototype.getDSTOffsetMinutes() returns the number of minutes offset of the DST. Date.prototype.setDSTOffsetMinutes(minutes) returns getDSTOffset or nothing, and minutes is the minutes DST offset you wish to set. it will only apply if DST is applicable to the timezone. the timezone must be applied first for this function to work properly. Date.prototype.setTimezoneOffsetMinutes(minutes) this sets the timezone ONLY, not TZ and DST. is is presumed that Date is DST-aware. Date.prototype.getTimezoneOffsetMinutes(minutes) this gets the timezone offset ONLY, not TZ and DST. is is now presumes that Date is DST-aware. btw, I think this needs to be added to Java's Calendar and Date as well, it lacks the functionality needed for DST. one possibility is, I just looked up Java equivalents that would fit this needed separate DST and TZ functionality within the Date object that are needed. http://docs.oracle.com/javase/6/docs/api/java/util/TimeZone.html http://docs.oracle.com/javase/6/docs/api/java/util/Calendar.html http://docs.oracle.com/javase/6/docs/api/java/util/GregorianCalendar.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5029449 these functions and classes I think would add the needed time functionality to javascript, and Java needs them as well.
This is outside the scope of the JavaScript / Web ECMAScript spec. See <http://javascript.spec.whatwg.org/#goals>. To propose new features to the ECMAScript language, please file a bug on https://bugs.ecmascript.org/.