Skip to content
This repository has been archived by the owner on Nov 8, 2017. It is now read-only.

Tests are failing because of timezone support #3

Closed
keithamus opened this issue Mar 14, 2012 · 3 comments
Closed

Tests are failing because of timezone support #3

keithamus opened this issue Mar 14, 2012 · 3 comments

Comments

@keithamus
Copy link
Owner

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:

  1. Rewrite all failing tests to be more timezone independent.
  2. 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.
@llafuente
Copy link

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 ?

@keithamus
Copy link
Owner Author

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:

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

@keithamus
Copy link
Owner Author

Closing for now. Going to aim for a new release some time this year which is a ground up rewrite.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants