You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 8, 2017. It is now read-only.
All tests are written to the UK locale, which means when they are loaded into a different locale, the test break. This is not necessarily code breaking (although it could be), but more that the tests are written too fixed.
Proposed Solutions:
Rewrite all failing tests to be more timezone independent.
Have & load in separate test suites for each timezone locale, which has the advantage of introducing locale specific tests, but the disadvantage of being a massive pain in the arse to maintain.
The text was updated successfully, but these errors were encountered:
Some test fail when computers are DST because Tempus asume that We want DST and that affects UTC methods, but in fact, I really believe that we should be able to change this behaviour, to force a timezone
I have the following propossal
// use the system timezone width DST, current behaviour
Tempus.setDefaultTimezone(false);
// use GMT+-<number> allways without DST, this must be added to test, so they dont fail
Tempus.setDefaultTimezone(<number>);
example: system: GMT+1 + DST (+2 total)
Tempus.setDefaultTimezone(false);
new Tempus(2011, 8, 11, 9, 30, 0) // Sun Sep 11 2011 09:30:00 +0200
Tempus.setDefaultTimezone(0);
new Tempus(2011, 8, 11, 9, 30, 0) // Sun Sep 11 2011 09:30:00 +0000
And i have to folowing doubt
new Tempus() // Wen Jun 20 2012 15:00:00 +0200
Tempus.setDefaultTimezone(0);
new Tempus(2011, 8, 11, 9, 30, 0) // Wen Jun 20 2012 15:00:00 +0000 or Wen Jun 20 2012 13:00:00 +0000 ??
I completely agree that you should be able to force Tempus not to follow DST changes. Have you seen the latest revision in master? It currently does this behaviour but in reverse. If you create a date with a fixed timezone offset, it will stay at that timezone until you run the setTimezoneToLocale() method, at which point it will set the timezone to the locales timezone, and start tracking DST changes.
My aim for this is to extend this (0.3 or 0.4) to allow setting of real timezones such as 'Europe/London' which will track DST and offset for THAT timezone rather than the clients locale.
-- Edit --
To expand on my comment, it means if you do:
vardate=newTempus().timezone('+02:00');// ^ Timezone will always be +02:00 and not track DST changesdate.setTimezoneToLocale();// ^ Timezone is now (I'm in UK) +01:00 (for British summer time) and// will change to +00:00 in Octoberdate=newTempus();// ^ Timezone is +01:00 (for BST) and will change to +00:00 in Oct
All tests are written to the UK locale, which means when they are loaded into a different locale, the test break. This is not necessarily code breaking (although it could be), but more that the tests are written too fixed.
Proposed Solutions:
The text was updated successfully, but these errors were encountered: