2014-06-08 19 views
5

Podczas tworzenia lub aktualizacji rekordu na żagle to napisać to w updateAt:Jak ustawić strefę czasową w Sails.js lub Express.js

updatedAt: 2014-07-06T15:00:00.000Z 

ale jestem w GMT + 2 godziny (w tym sezonie) i aktualizacja jest wykonywana o 16:00.

Mam ten sam problem ze wszystkimi polami datetime zadeklarowanymi w moich modelach.

Jak ustawić właściwą strefę czasową na Żagle (lub ewentualnie Express)?

+0

ustawienie czasu lokalnego na serwerze, na którym działa aplikacja. Czyż nie? – diproart

Odpowiedz

1

Próba rozwiązania problemu poprzez ustawienie strefy czasowej na serwerze jest trochę krótkowzroczna. Co się stanie, jeśli się przeprowadzisz? Czy ktoś z innego kraju ma dostęp do Twojej aplikacji? Ważne jest to, że znaczniki czasowe w bazie danych mają zakodowaną strefę czasową, dzięki czemu można tłumaczyć na właściwy czas na przednim końcu. Oznacza to, że jeśli:

new Date('2014-07-06T15:00:00.000Z') 

w konsoli przeglądarki, powinieneś zobaczyć, że wyświetla prawidłową datę i godzinę, gdziekolwiek jesteś. Żagle automatycznie kodują ten znacznik czasu za pomocą domyślnych pól updatedAt i createdAt; po prostu upewnij się, że zawsze używasz strefy czasowej podczas zapisywania niestandardowych znaczników czasu do bazy danych i powinieneś być w porządku!

0

Doszedłem do wniosku, że nie ustawiam strefy czasowej na poziomie aplikacji (rozumiem, dlaczego autorzy żagli robili to w ten sposób), jednak miałem trudny czas, wykonując proste zapytanie o dopasowanie do daty. Zakładam, że jeśli utworzysz rekord przy użyciu domyślnych metod planistycznych (ten zawierający dodatkowe pole datetime zamiast domyślnych), przekazując datę, że będziesz w stanie przekazać tę samą datę w zapytaniu uzyskać ten sam rekord.

Załóżmy na przykład, że pole datetime jest nazywane "datą specjalną". Jeśli utworzę nowy rekord za pomocą api z "specjalną datą" równą "06-09-2014" (ignorując czas), nie jestem w stanie uruchomić zapytania, w którym mogę przejść w "06-09-2014" i odzyskaj tę płytę. Większe niż zapytania działają dobrze (jeśli znajdę datę większą niż ta). Jestem pewien, że jest to przesunięcie czasowe, ale nie udało się znaleźć rozwiązania.

2

I rozwiązać ten problem, należy ustawienie pliku opcji MySQL do zmiany strefy czasowej UTC w config/connections.js ustawienie w tym

devMysqlServer: { 
    adapter: 'sails-mysql', 
    host: '127.0.0.1', 
    user: 'root', 
    password: '***', 
    database: '**', 
    timezone: 'utc' 
    }, 
1

Najlepszy planowaniu architektury tutaj, IMO, jest kontynuować korzystanie z formatowania izoDate Sails.js. Kiedy użytkownik załaduje twoją witrynę/aplikację, isoDate zostanie przekonwertowane na strefę czasową klienta/przeglądarki, która zazwyczaj jest ustawiona na poziomie systemu operacyjnego.

Oto przykład, na który możesz to przetestować. Otwórz konsolę przeglądarki i uruchom new Date().toISOString() i sprawdź ustawiony czas. To będzie oparte na specyfikacji dla isoDate 8601 (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toISOString). Teraz zmień czas systemowy na inną strefę czasową lub po prostu zmień godzinę i zaoszczędź (nie powinieneś ładować ponownie, jeśli używasz konsoli chrome). Ponownie uruchom komendę w konsoli new Date().toISOString(), a otrzymasz dostosowany czas odpowiedni do czasu, który właśnie zmieniłeś.

Jeśli chcesz dalej udowadniać, że czas jest odpowiedni dla Sails.js, użyj Moment.js na isoDate, który jest przechowywany w bazie danych (utworzonej przez ORM), tak jak moment("2016-02-05T22:36:48.800Z").fromNow(), a Ty " Zauważ, że czas jest relatywny do czasu systemowego.

7

Sposób, w jaki obsługiwane problem po wielu godzinach badań:

Put process.env.TZ = 'UTC'; //whatever timezone you want

w config/bootstrap.js

+0

Działa, gdy działam na środowisku programistycznym, ale to nie działa w produkcji env – Arshad

+0

to jest idealne rozwiązanie działa dla mnie. –

Powiązane problemy