Aktywne Wpisy
qaluhilak +88
#tldr chłop się topił we Wrocławiu w fosie miejskiej, przepraszam za skladnie i błędy ale chciałem to opisać na świeżo i nie mam sily tego redagować, bardzo ciekawy wątek policyjny i nie tylko ( ͡º ͜ʖ͡º) akcja działa się koło 22:30 25.10
Na czerowno miejsce gdzie wpadł do wody i gdzie stałem z krzyczącym policjantem a na zielono miejsce gdzie go uratowali.#wroclaw
#112 #policja
Co za akcja
Na czerowno miejsce gdzie wpadł do wody i gdzie stałem z krzyczącym policjantem a na zielono miejsce gdzie go uratowali.#wroclaw
#112 #policja
Co za akcja
Cancermoon +11
Prawda to taka jest ze albo sie urodzisz z jakims talentem i ktos ci go pokaze i to wykorzystasz albo cale zycie kolchoz
Aktywne Znaleziska
Dlaczego?
- Do UTC są domyślne metody, a jak lubicie funkcyjnie, to date-fns robi robotę i jest leciutki.
- Większość bazodanowych ORM domyślnie w dialekcie konwertuje do UTC. Nie trzeba dodawać customowych configów, by temu zapobiec (i dobrze, bo nie powinno się tego zmieniać).
- Przy czasie lokalnym, gdy zmienicie lokalizację serwera bez przestawienia timezone na serwerze, z tych samych danych, mogą powstawać inne wyniki. Niby można czas na serwerze przestawić, a jak niemożna, to apkę wirtualizować, ale po co dodawać roboty? Użyj UTC!
- Bez UTC, jak masz międzynarodowy team, to po jednej stronie wody testy przechodzą, a po drugiej nie.
- Konwersja z UTC, do dowolnego czasu lokalnego jest banalnie prosta, zazwyczaj nawet nie musisz się tym przejmować.
Jak sobie poradzić, gdy już masz czas lokalny? Wirtualizacja, ewentualnie moment.js.
Bo chyba nie będziesz wszystkiego przepisywać na UTC, prawda? ( ͡° ͜ʖ ͡°)
TL;DR
#javascript #nodejs #naukaprogramowania #programowanie i jeszcze #protip
Oczywiście zależnie od języka i bibliotek/frameworków możemy tym sposobem pozbawić się manipulacji czasem za pomocą gotowych funkcji
https://en.wikipedia.org/wiki/Unix_time
@niepodszywamsiepodbiauka: niby tak, ale nie do końca. Wyobraźmy sobie, że robisz kalendarz i do kalendarza sobie wpisujesz, że będzie spotkanie 24 lutego 2022 roku o 15:00 (np. w Krakowie). Wszystko spoko, zapisujemy sobie datę
24 lutego 2022 roku o 14:00 UTC(czyli 15:00 CET). Następnie wchodzi plan, by zrezygnować ze zmiany czasu na letni w@alex-fortune: Timestampy mają swoje wady. Zresztą, ta nazwa mówi sama przez się. Trudno się na nich operuje, nie posiadają paru haków (leap second), w logice zamiast nazw, zaczynasz używać magic numbers albo definiujesz całą stertę dziwnych stałych, a z samej liczby nie jesteś wstanie powiedzieć na jakiej dacie konkretnie jesteś
@niepodszywamsiepodbiauka: tak, dla tego w podanym przeze mnie przypadku zapisujesz datę bez strefy czasowej "tak jak jest" bez zabawy z zamianą na UTC czy w drugą stronę.
@alex-fortune: heh, oprócz tego co powiedziała @niepodszywamsiepodbiauka (leap seconds) to jeszcze jest sporo rzeczy, których timestampy zwyczajnie nie potrafią ogarnąć same z siebie (lub działają "wolniej" jeśli
- dzień
- miesiąc
- rok
- godzina
- minuta
- sekunda
- nanosekunda
Dodatkowo dodajesz strefę czasową jeśli składujesz czas ze strefą.
Na serwerze Node.js używam moment-timezone:
const getMonthTimestamp = () =>moment()
.tz('Europe/Warsaw')
.date(1)
.hour(0)
.minute(0)
.seconds(0)
.unix()
W przeglądarce:
const getMonthTimestamp = () =>+new Date((new Date).getFullYear(), (new Date).getMonth()) / 1000
Nie jestem pewien, czy jeśli bym zrezygnował z moment-timezone i używał tej drugiej funkcji na serwerze,
Poczytałem trochę i doszedłem do wniosku, że w moim przypadku najlepiej będzie zamiast timestampów zapisywać w bazie UTC z zerowym offsetem.
Powyższa funkcja wyglądałaby tak:
new Date((new Date).getUTCFullYear(), (new Date).getUTCMonth()).toISOString()i zwraca
2019-05-31T22:00:00.000ZJak dla danego dnia lub miesiąca mam tę samą wartość czasową to mogę sobie je prosto pogrupować funkcjami agregującymi.
powinno być
bo działamy na czasie lokalnym i później konwertujemy na UTC z zerowym offsetem