Closed keithamus closed 8 years ago
Hi,
I found another problem related to this issue.
You can find the test in this gist: https://gist.github.com/2959817
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 ??
What do you think ?
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.
To expand on my comment, it means if you do:
var date = new Tempus().timezone('+02:00');
// ^ Timezone will always be +02:00 and not track DST changes
date.setTimezoneToLocale();
// ^ Timezone is now (I'm in UK) +01:00 (for British summer time) and
// will change to +00:00 in October
date = new Tempus();
// ^ Timezone is +01:00 (for BST) and will change to +00:00 in Oct
Closing for now. Going to aim for a new release some time this year which is a ground up rewrite.
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: