15.9.1.1 Étendue du temps Le temps est mesuré dans ECMAScript en millisecondes depuis le 1er janvier 1970, TU. Les secondes intercalaires sont ignorées.
Je crois que j'ai lu que, dans certains systèmes UNIX ou LINUX, JavaScript appels des routines système pour aider à faire date / heure de travail, et que donc les effets des secondes intercalaires peuvent apparir.
I believe that I have read that, in some UNIX or LINUX systems, JavaScript calls system routines to help to do date/time work, and that therefore the effects of leap seconds may appear.
Il est normal que JavaScript passe par les appels système de la machine pour obtenir la date courante et l'heure courante. En revanche, pour les calculs faits par les fonctions setHours, setMinutes, setSeconds, setTime, et ainsi de suite, tous les algorithmes sont explicités dans les moindres détails par la norme ECMAScript : une implémentation qui ne les respecterait pas ne serait donc pas standard.
Je serais intéressé d'entendre de telles observations.
I would be interested to hear of any such observations.
Moi aussi.
Ich auch.
Le 26/01/2009 22:27, Dr J R Stockton a écrit :
Traduction perso :
15.9.1.1 Étendue du temps
Le temps est mesuré dans ECMAScript en millisecondes depuis le 1er
janvier 1970, TU. Les secondes intercalaires sont ignorées.
Je crois que j'ai lu que, dans certains systèmes UNIX ou LINUX,
JavaScript appels des routines système pour aider à faire date / heure
de travail, et que donc les effets des secondes intercalaires peuvent
apparir.
I believe that I have read that, in some UNIX or LINUX systems,
JavaScript calls system routines to help to do date/time work, and that
therefore the effects of leap seconds may appear.
Il est normal que JavaScript passe par les appels système de la machine
pour obtenir la date courante et l'heure courante. En revanche, pour
les calculs faits par les fonctions setHours, setMinutes, setSeconds,
setTime, et ainsi de suite, tous les algorithmes sont explicités dans
les moindres détails par la norme ECMAScript : une implémentation qui
ne les respecterait pas ne serait donc pas standard.
Je serais intéressé d'entendre de telles observations.
I would be interested to hear of any such observations.
15.9.1.1 Étendue du temps Le temps est mesuré dans ECMAScript en millisecondes depuis le 1er janvier 1970, TU. Les secondes intercalaires sont ignorées.
Je crois que j'ai lu que, dans certains systèmes UNIX ou LINUX, JavaScript appels des routines système pour aider à faire date / heure de travail, et que donc les effets des secondes intercalaires peuvent apparir.
I believe that I have read that, in some UNIX or LINUX systems, JavaScript calls system routines to help to do date/time work, and that therefore the effects of leap seconds may appear.
Il est normal que JavaScript passe par les appels système de la machine pour obtenir la date courante et l'heure courante. En revanche, pour les calculs faits par les fonctions setHours, setMinutes, setSeconds, setTime, et ainsi de suite, tous les algorithmes sont explicités dans les moindres détails par la norme ECMAScript : une implémentation qui ne les respecterait pas ne serait donc pas standard.
Je serais intéressé d'entendre de telles observations.
I would be interested to hear of any such observations.
Moi aussi.
Ich auch.
Dr J R Stockton
En fr.comp.lang.javascript message <497f1d4a$, 27 Jan 2009 15:43:06, Olivier Miakinen <om+ a écrit:
Le 26/01/2009 22:27, Dr J R Stockton a écrit :
Je crois que j'ai lu que, dans certains systèmes UNIX ou LINUX, JavaScript appels des routines système pour aider à faire date / heure de travail, et que donc les effets des secondes intercalaires peuvent apparir.
I believe that I have read that, in some UNIX or LINUX systems, JavaScript calls system routines to help to do date/time work, and that therefore the effects of leap seconds may appear.
Il est normal que JavaScript passe par les appels système de la machine pour obtenir la date courante et l'heure courante.
C'est ca. A 2010-01-01 00:00:00 GMT, le temps sera quarante ans apres l'Epoch 1970-01-01 00:00:00. Donc, a cette instant, new Date() dans un PC fixe la date d'objet à 40 * 365,25 * 864e5 millisecondes, depuis un PC ordinaire ne sait rien de secondes supplementaires. Mais, si un système UNIX utilisés, le code de new Date () peut recevoir 1000 * time_t et time_t peut être 40 * 365,25 * 864e2 + 34, car il ya eu en effet 34 secondes supplementaires depuis 1970 (peut-être 35).
En revanche, pour les calculs faits par les fonctions setHours, setMinutes, setSeconds, setTime, et ainsi de suite, tous les algorithmes sont explicités dans les moindres détails par la norme ECMAScript : une implémentation qui ne les respecterait pas ne serait donc pas standard.
C'est ca. <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre que pas tous les navigateurs actuels sont totalement conformes, et aussi <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> rapports sur Opera 9.21 .. 9.27, 9.50 .. 9.61, j'ai vu, avec un XP système mis du temps pour le Royaume-Uni, une erreur d'un jour à proximité de la plupart des Summer Time transitions avant 1970 et apres 2038. Note: c'est l'extérieur de la positive signé 32 bits de secondes- de-1970,0 gamme. IIRC, ailleurs, les résultats diffèrent.
Il semble possible, aussi, que le Javascript peut (pour la commodité des programmeurs de systèmes), le système de date / heure de la bibliothèque pour la date / heure de l'arithmétique, sans le savoir / en tenant compte de / s'occuper d'une très bonne bibliothèque peut être incompatible avec la norme ISO / IEC 16262 .
Il est dommage que Google traduit "may" en "mai". "May" est "Mai", mais "may" est généralement "peut" ou similaire. Je leur ai dit.
-- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
En fr.comp.lang.javascript message <497f1d4a$1@neottia.net>, 27 Jan 2009
15:43:06, Olivier Miakinen <om+news@miakinen.net> a écrit:
Le 26/01/2009 22:27, Dr J R Stockton a écrit :
Je crois que j'ai lu que, dans certains systèmes UNIX ou LINUX,
JavaScript appels des routines système pour aider à faire date / heure
de travail, et que donc les effets des secondes intercalaires peuvent
apparir.
I believe that I have read that, in some UNIX or LINUX systems,
JavaScript calls system routines to help to do date/time work, and that
therefore the effects of leap seconds may appear.
Il est normal que JavaScript passe par les appels système de la machine
pour obtenir la date courante et l'heure courante.
C'est ca. A 2010-01-01 00:00:00 GMT, le temps sera quarante ans apres
l'Epoch 1970-01-01 00:00:00. Donc, a cette instant, new Date()
dans un PC fixe la date d'objet à 40 * 365,25 * 864e5 millisecondes,
depuis un PC ordinaire ne sait rien de secondes supplementaires. Mais,
si un système UNIX utilisés, le code de new Date () peut recevoir 1000 *
time_t et time_t peut être 40 * 365,25 * 864e2 + 34, car il ya eu en
effet 34 secondes supplementaires depuis 1970 (peut-être 35).
En revanche, pour
les calculs faits par les fonctions setHours, setMinutes, setSeconds,
setTime, et ainsi de suite, tous les algorithmes sont explicités dans
les moindres détails par la norme ECMAScript : une implémentation qui
ne les respecterait pas ne serait donc pas standard.
C'est ca. <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre
que pas tous les navigateurs actuels sont totalement conformes, et aussi
<URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> rapports
sur Opera 9.21 .. 9.27, 9.50 .. 9.61, j'ai vu, avec un XP
système mis du temps pour le Royaume-Uni, une erreur d'un jour à
proximité de la plupart des Summer Time transitions avant 1970 et apres
2038. Note: c'est l'extérieur de la positive signé 32 bits de secondes-
de-1970,0 gamme. IIRC, ailleurs, les résultats diffèrent.
Il semble possible, aussi, que le Javascript peut (pour la commodité des
programmeurs de systèmes), le système de date / heure de la bibliothèque
pour la date / heure de l'arithmétique, sans le savoir / en tenant
compte de / s'occuper d'une très bonne bibliothèque peut être
incompatible avec la norme ISO / IEC 16262 .
Il est dommage que Google traduit "may" en "mai". "May" est "Mai",
mais "may" est généralement "peut" ou similaire. Je leur ai dit.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
En fr.comp.lang.javascript message <497f1d4a$, 27 Jan 2009 15:43:06, Olivier Miakinen <om+ a écrit:
Le 26/01/2009 22:27, Dr J R Stockton a écrit :
Je crois que j'ai lu que, dans certains systèmes UNIX ou LINUX, JavaScript appels des routines système pour aider à faire date / heure de travail, et que donc les effets des secondes intercalaires peuvent apparir.
I believe that I have read that, in some UNIX or LINUX systems, JavaScript calls system routines to help to do date/time work, and that therefore the effects of leap seconds may appear.
Il est normal que JavaScript passe par les appels système de la machine pour obtenir la date courante et l'heure courante.
C'est ca. A 2010-01-01 00:00:00 GMT, le temps sera quarante ans apres l'Epoch 1970-01-01 00:00:00. Donc, a cette instant, new Date() dans un PC fixe la date d'objet à 40 * 365,25 * 864e5 millisecondes, depuis un PC ordinaire ne sait rien de secondes supplementaires. Mais, si un système UNIX utilisés, le code de new Date () peut recevoir 1000 * time_t et time_t peut être 40 * 365,25 * 864e2 + 34, car il ya eu en effet 34 secondes supplementaires depuis 1970 (peut-être 35).
En revanche, pour les calculs faits par les fonctions setHours, setMinutes, setSeconds, setTime, et ainsi de suite, tous les algorithmes sont explicités dans les moindres détails par la norme ECMAScript : une implémentation qui ne les respecterait pas ne serait donc pas standard.
C'est ca. <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre que pas tous les navigateurs actuels sont totalement conformes, et aussi <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> rapports sur Opera 9.21 .. 9.27, 9.50 .. 9.61, j'ai vu, avec un XP système mis du temps pour le Royaume-Uni, une erreur d'un jour à proximité de la plupart des Summer Time transitions avant 1970 et apres 2038. Note: c'est l'extérieur de la positive signé 32 bits de secondes- de-1970,0 gamme. IIRC, ailleurs, les résultats diffèrent.
Il semble possible, aussi, que le Javascript peut (pour la commodité des programmeurs de systèmes), le système de date / heure de la bibliothèque pour la date / heure de l'arithmétique, sans le savoir / en tenant compte de / s'occuper d'une très bonne bibliothèque peut être incompatible avec la norme ISO / IEC 16262 .
Il est dommage que Google traduit "may" en "mai". "May" est "Mai", mais "may" est généralement "peut" ou similaire. Je leur ai dit.
-- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Olivier Miakinen
Le 27/01/2009 21:28, Dr J R Stockton a écrit :
Il est normal que JavaScript passe par les appels système de la machine pour obtenir la date courante et l'heure courante.
C'est ca. A 2010-01-01 00:00:00 GMT, le temps sera quarante ans apres l'Epoch 1970-01-01 00:00:00. Donc, a cette instant, new Date() dans un PC fixe la date d'objet à 40 * 365,25 * 864e5 millisecondes, depuis un PC ordinaire ne sait rien de secondes supplementaires.
Ok avec ça.
Mais, si un système UNIX utilisés, le code de new Date () peut recevoir 1000 * time_t et time_t peut être 40 * 365,25 * 864e2 + 34, car il ya eu en effet 34 secondes supplementaires depuis 1970 (peut-être 35).
Pourtant, je lis ceci, qui correspond bien à la notion que j'avais du « temps Unix » :
<cit. http://en.wikipedia.org/wiki/Unix_time> Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds. </cit.>
« not counting leap seconds » = « sans compter les secondes intercalaires »
Et aussi :
<cit. http://en.wikipedia.org/wiki/Unix_time> It is neither a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60). </cit.>
« il n'a aucun moyen de représenter les secondes intercalaires »
Ainsi, même sur un système Unix il ne devrait pas y avoir cette différence de 34 secondes que tu crains. À l'occasion j'essaierai sur un AIX (mais c'est la version de JavaScript qui sera très vieille car il n'y a que Netscape 4 dessus).
[...] <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre que pas tous les navigateurs actuels sont totalement conformes
Très intéressant ce tableau comparatif, merci. Pour info, je peux te dire que SeaMonkey 1.1.14 se comporte exactement comme Firefox 2.0.0.3 à 2.0.0.16, c'est-à-dire comme Firefox 3 sauf pour la première valeur qui est false et non pas true.
et aussi <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto>
C'est exactement la même URL. C'est voulu ?
Il semble possible, aussi, que le Javascript peut (pour la commodité des programmeurs de systèmes), le système de date / heure de la bibliothèque pour la date / heure de l'arithmétique, sans le savoir / en tenant compte de / s'occuper d'une très bonne bibliothèque peut être incompatible avec la norme ISO / IEC 16262 .
Je n'ai pas tout compris, mais je pense saisir l'idée générale. Oui, le JavaScript pourrait se baser sur une bibliothèque système dont il croit qu'elle respecte le standard, alors que c'est faux.
Le 27/01/2009 21:28, Dr J R Stockton a écrit :
Il est normal que JavaScript passe par les appels système de la machine
pour obtenir la date courante et l'heure courante.
C'est ca. A 2010-01-01 00:00:00 GMT, le temps sera quarante ans apres
l'Epoch 1970-01-01 00:00:00. Donc, a cette instant, new Date()
dans un PC fixe la date d'objet à 40 * 365,25 * 864e5 millisecondes,
depuis un PC ordinaire ne sait rien de secondes supplementaires.
Ok avec ça.
Mais,
si un système UNIX utilisés, le code de new Date () peut recevoir 1000 *
time_t et time_t peut être 40 * 365,25 * 864e2 + 34, car il ya eu en
effet 34 secondes supplementaires depuis 1970 (peut-être 35).
Pourtant, je lis ceci, qui correspond bien à la notion que j'avais du
« temps Unix » :
<cit. http://en.wikipedia.org/wiki/Unix_time>
Unix time, or POSIX time, is a system for describing points in time,
defined as the number of seconds elapsed since midnight Coordinated
Universal Time (UTC) of January 1, 1970, not counting leap seconds.
</cit.>
« not counting leap seconds » = « sans compter les secondes
intercalaires »
Et aussi :
<cit. http://en.wikipedia.org/wiki/Unix_time>
It is neither a linear representation of time nor a true representation
of UTC (though it is frequently mistaken for both) as the times it
represents are UTC but it has no way of representing UTC leap seconds
(e.g. 1998-12-31 23:59:60).
</cit.>
« il n'a aucun moyen de représenter les secondes intercalaires »
Ainsi, même sur un système Unix il ne devrait pas y avoir cette
différence de 34 secondes que tu crains. À l'occasion j'essaierai sur
un AIX (mais c'est la version de JavaScript qui sera très vieille car
il n'y a que Netscape 4 dessus).
[...] <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre
que pas tous les navigateurs actuels sont totalement conformes
Très intéressant ce tableau comparatif, merci. Pour info, je peux te
dire que SeaMonkey 1.1.14 se comporte exactement comme Firefox 2.0.0.3 à
2.0.0.16, c'est-à-dire comme Firefox 3 sauf pour la première valeur qui
est false et non pas true.
et aussi
<URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto>
C'est exactement la même URL. C'est voulu ?
Il semble possible, aussi, que le Javascript peut (pour la commodité des
programmeurs de systèmes), le système de date / heure de la bibliothèque
pour la date / heure de l'arithmétique, sans le savoir / en tenant
compte de / s'occuper d'une très bonne bibliothèque peut être
incompatible avec la norme ISO / IEC 16262 .
Je n'ai pas tout compris, mais je pense saisir l'idée générale. Oui, le
JavaScript pourrait se baser sur une bibliothèque système dont il croit
qu'elle respecte le standard, alors que c'est faux.
Il est normal que JavaScript passe par les appels système de la machine pour obtenir la date courante et l'heure courante.
C'est ca. A 2010-01-01 00:00:00 GMT, le temps sera quarante ans apres l'Epoch 1970-01-01 00:00:00. Donc, a cette instant, new Date() dans un PC fixe la date d'objet à 40 * 365,25 * 864e5 millisecondes, depuis un PC ordinaire ne sait rien de secondes supplementaires.
Ok avec ça.
Mais, si un système UNIX utilisés, le code de new Date () peut recevoir 1000 * time_t et time_t peut être 40 * 365,25 * 864e2 + 34, car il ya eu en effet 34 secondes supplementaires depuis 1970 (peut-être 35).
Pourtant, je lis ceci, qui correspond bien à la notion que j'avais du « temps Unix » :
<cit. http://en.wikipedia.org/wiki/Unix_time> Unix time, or POSIX time, is a system for describing points in time, defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds. </cit.>
« not counting leap seconds » = « sans compter les secondes intercalaires »
Et aussi :
<cit. http://en.wikipedia.org/wiki/Unix_time> It is neither a linear representation of time nor a true representation of UTC (though it is frequently mistaken for both) as the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60). </cit.>
« il n'a aucun moyen de représenter les secondes intercalaires »
Ainsi, même sur un système Unix il ne devrait pas y avoir cette différence de 34 secondes que tu crains. À l'occasion j'essaierai sur un AIX (mais c'est la version de JavaScript qui sera très vieille car il n'y a que Netscape 4 dessus).
[...] <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre que pas tous les navigateurs actuels sont totalement conformes
Très intéressant ce tableau comparatif, merci. Pour info, je peux te dire que SeaMonkey 1.1.14 se comporte exactement comme Firefox 2.0.0.3 à 2.0.0.16, c'est-à-dire comme Firefox 3 sauf pour la première valeur qui est false et non pas true.
et aussi <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto>
C'est exactement la même URL. C'est voulu ?
Il semble possible, aussi, que le Javascript peut (pour la commodité des programmeurs de systèmes), le système de date / heure de la bibliothèque pour la date / heure de l'arithmétique, sans le savoir / en tenant compte de / s'occuper d'une très bonne bibliothèque peut être incompatible avec la norme ISO / IEC 16262 .
Je n'ai pas tout compris, mais je pense saisir l'idée générale. Oui, le JavaScript pourrait se baser sur une bibliothèque système dont il croit qu'elle respecte le standard, alors que c'est faux.
Dr J R Stockton
En fr.comp.lang.javascript message <4980d9ff$, 28 Jan 2009 23:19:42, Olivier Miakinen <om+ a écrit:
Non :-(. #2, pas #Auto, mais #OST (3 sub-sections).
C'est ca. <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre que pas tous les navigateurs actuels sont totalement conformes, et aussi <URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> rapports sur Opera 9.21 .. 9.27, 9.50 .. 9.61, j'ai vu, avec un XP système mis du temps pour le Royaume-Uni, une erreur d'un jour à proximité de la plupart des Summer Time transitions avant 1970 et apres 2038. Note: c'est l'extérieur de la positive signé 32 bits de secondes- de-1970,0 gamme. IIRC, ailleurs, les résultats diffèrent.
-- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links; <URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ; <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
En fr.comp.lang.javascript message <4980d9ff$1@neottia.net>, 28 Jan 2009
23:19:42, Olivier Miakinen <om+news@miakinen.net> a écrit:
Non :-(. #2, pas #Auto, mais #OST (3 sub-sections).
C'est ca. <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre
que pas tous les navigateurs actuels sont totalement conformes, et aussi
<URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> rapports
sur Opera 9.21 .. 9.27, 9.50 .. 9.61, j'ai vu, avec un XP
système mis du temps pour le Royaume-Uni, une erreur d'un jour à
proximité de la plupart des Summer Time transitions avant 1970 et apres
2038. Note: c'est l'extérieur de la positive signé 32 bits de secondes-
de-1970,0 gamme. IIRC, ailleurs, les résultats diffèrent.
--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
Non :-(. #2, pas #Auto, mais #OST (3 sub-sections).
C'est ca. <URL:http://www.merlyn.demon.co.uk/js-datex.htm#Auto> montre que pas tous les navigateurs actuels sont totalement conformes, et aussi <URL:http://www.merlyn.demon.co.uk/js-datex.htm#OST> rapports sur Opera 9.21 .. 9.27, 9.50 .. 9.61, j'ai vu, avec un XP système mis du temps pour le Royaume-Uni, une erreur d'un jour à proximité de la plupart des Summer Time transitions avant 1970 et apres 2038. Note: c'est l'extérieur de la positive signé 32 bits de secondes- de-1970,0 gamme. IIRC, ailleurs, les résultats diffèrent.
-- (c) John Stockton, nr London UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links; <URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ; <URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
