Wpis z mikrobloga

Do tego dochodzą systemy które korzystają z UTC


@plushy: I systemy z błędnie skonfigurowaną strefą czasową, która aktualnie przypadkowo jest równa prawidłowej poza nazwą, a po zmianach jeżeli różne kraje podejmą różne decyzje przestanie być równa.

Na przykład jest widoczna dla użytkownika lista stref czasowych, gdzie jedną z pozycji jest "Sarajewo, Skopie, Warszawa, Zagrzeb", ktoś to wybrał w Polsce myśląc o Warszawie, w wyniku czego backend ustawił Europe/Sarajevo, co teraz działa,
@ElGovanni: ciekawa historia jest taka, ze owszem, zmian czasu nie będzie, ale to kraje czlonkowskie maja decydowac, czy zostac przy letnim, czy zimowym, to dopiero beda cuda sie dzialy ( ͡° ͜ʖ ͡°)
@Pathfinder007: owszem Oracle ogarnie, ale w nowej Javie (9, 10, 11).

A Java 8 (czyli obecnie raczej standard, bo na 9/10 mało firm przechodzi, bo nie jest jeszcze LTS, dopiero 11), będzie miała niedługo płatne aktualizacje: https://www.aspera.com/en/blog/oracle-will-charge-for-java-starting-in-2019/

Czyli firmy mają taki wybór
- przejść z Javy 8 na Java 10, a potem z Javy 10 na Javę 11 (duże koszty, nie wszystkie systemy łatwo się upgrdują),
- przejść z Javy 8
Datę masz zapisaną często jako jedną liczbę - ilość milisekund od 1 stycznia 1970


@ZasilaczKomputerowy: @Khaine: timestamp czy UTC+0 to żadna różnica (jedna linia kodu na zmianę). Chodzi o to, że ten format, to czas systemowy w strefie UTC+0.

Do lokalnego działania aplikacji jest to ok, żadnych problemów, dlatego tak się robi.

Ale są przypadki, w których musisz uwzględniać strefy czasowe np.
- chcesz wyświetlić datę użytkownikowi, chyba nie każesz