🚀 go-pugleaf

On 24.03.2017 12:33, Piotr Gałka wrote:
> Przed chwilą - czyli gdy jest godzina 12 coś.
> Pod Builderem 5 pobrałem czas funkcją time() i z tego wyliczyłem (nie
> korzystając z żadnych gotowych funkcji jaką mamy godzinę.
> Wyszło mi 11 i to się zgadza z czasem Greenwich.
> Następnie ^C ^V ten kawałek programu do Buildera 2010 i tu (na tym samym
> komputerze) wychodzi, że jest godzina 10.
> Ki czort - to nie jest żaden rozsądny czas.



> Mój problem - chcę pod Builderem 2010 dostać aktualny czas Greenwich w
> formacie Unix. Myślałem, że time() mi to daje.

Wygląda na to, że nie ma takiego obowiązku. Jak zaimplementują, tak
będzie:) Czas uniwersalny dostaniesz przepuszczając to przez gmtime,
a czas z lokali - przez localtime.



"The value returned generally represents the number of seconds since 
00:00 hours, Jan 1, 1970 UTC (i.e., the current unix timestamp). 
Although libraries may use a different representation of time: Portable 
programs should not use the value returned by this function directly, 
but always rely on calls to other elements of the standard library to 
translate them to portable types (such as localtime, gmtime or difftime)."
http://www.cplusplus.com/reference/ctime/time/

pzdr
bartekltg

W dniu 2017-03-24 o 13:18, bartekltg pisze:
>
> Wygląda na to, że nie ma takiego obowiązku. Jak zaimplementują, tak
> będzie:) Czas uniwersalny dostaniesz przepuszczając to przez gmtime,
> a czas z lokali - przez localtime.
>
>
>
> "The value returned generally represents the number of seconds since
> 00:00 hours, Jan 1, 1970 UTC (i.e., the current unix timestamp).
> Although libraries may use a different representation of time: Portable
> programs should not use the value returned by this function directly,
> but always rely on calls to other elements of the standard library to
> translate them to portable types (such as localtime, gmtime or difftime)."
> http://www.cplusplus.com/reference/ctime/time/
>
Dzięki.
W międzyczasie kolega podsunął mi taki przykład:
FILETIME time;
  GetSystemTimeAsFileTime(&time);
  return ((unsigned long long)(((_LARGE_INTEGER*)&time)->QuadPart - 
116444736000000000LL)) / ((unsigned long long)10000000LL);

który ja sobie uprościłem do:
(*(qword*)&time)/10000000-11644473600LL
gdzie qword to moje typedef dla unsigned __int64

i to daje prawidłowy czas, ale nie wiem, czy mam gwarancje :)

Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba 
przeliczać na sekundy uwzględniając lata przestępne itd.
P.G.

On 24.03.2017 14:47, Piotr Gałka wrote:
> W dniu 2017-03-24 o 13:18, bartekltg pisze:
>>
>> Wygląda na to, że nie ma takiego obowiązku. Jak zaimplementują, tak
>> będzie:) Czas uniwersalny dostaniesz przepuszczając to przez gmtime,
>> a czas z lokali - przez localtime.
>>
>>
>>
>> "The value returned generally represents the number of seconds since
>> 00:00 hours, Jan 1, 1970 UTC (i.e., the current unix timestamp).
>> Although libraries may use a different representation of time: Portable
>> programs should not use the value returned by this function directly,
>> but always rely on calls to other elements of the standard library to
>> translate them to portable types (such as localtime, gmtime or
>> difftime)."
>> http://www.cplusplus.com/reference/ctime/time/
>>
> Dzięki.
> W międzyczasie kolega podsunął mi taki przykład:
> FILETIME time;
>  GetSystemTimeAsFileTime(&time);
>  return ((unsigned long long)(((_LARGE_INTEGER*)&time)->QuadPart -
> 116444736000000000LL)) / ((unsigned long long)10000000LL);
>
> który ja sobie uprościłem do:
> (*(qword*)&time)/10000000-11644473600LL
> gdzie qword to moje typedef dla unsigned __int64
>
> i to daje prawidłowy czas, ale nie wiem, czy mam gwarancje :)

Ale znów, raz bedzeisz miał czas dobry, a na inym kompilatorze zły ;-)

>
> Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba
> przeliczać na sekundy uwzględniając lata przestępne itd.

Może difftime? Daje roznicę dwóch time_t w sekundach.
Tylko trzeba spreparować taki time_t z punktem startu,
ale to już mniejszy problem.

Raczej bym próbował tak niż samemu bawic się bitami.
A nuż inna wersja borlanda uzywa jeszcze innej epoki,
na linuxie unixtime, a na wisdowsie wspomniany wyzej FILETIME,
który mierzy od 1601 roku.


Jak to c++, to pewnie warto przejrzeć, co jest w  std::chrono.

pzdr
bartekltg

Piotr Gałka <piotr.galka@cutthismicromade.pl> wrote:

> Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba 
> przeliczać na sekundy uwzględniając lata przestępne itd.

Może najpierw gmtime, a potem strftime z formatem %s?

-- 
http://www.chmurka.net/

Adam Wysocki <gof@somewhere.invalid> wrote:

>> Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba 
>> przeliczać na sekundy uwzględniając lata przestępne itd.
> 
> Może najpierw gmtime, a potem strftime z formatem %s?

Lub gmtime i mktime.

-- 
http://www.chmurka.net/

W dniu 2017-03-24 o 15:06, bartekltg pisze:

>>  GetSystemTimeAsFileTime(&time);

> Ale znów, raz bedzeisz miał czas dobry, a na inym kompilatorze zły ;-)
>
Opierając się na tym co kolega powiedział:
SystemTime to czas Greenwich, a LocalTime to lokalny.
Jeśli to prawda to powinno zawsze być ok.
Na razie mi się zgodziło.

> Może difftime? Daje roznicę dwóch time_t w sekundach.
> Tylko trzeba spreparować taki time_t z punktem startu,
> ale to już mniejszy problem.
>

Kiedyś bardzo dawno (lata 90-te) zrobiłem sobie rysunek zbierający 
funkcje dotyczące czasu.
Między węzłem Zegar a time_t mam funkcje time() i stime().
Między time_t a struct tm mam funkcje localtime() i mktime().
I przynajmniej na tym moim rysunku mktime() to jedyna funkcja 
wytwarzająca czas w postaci time_t.
Jeśli mktime() jest odwrotną do localtime() to wymaga czasu lokalnego. 
Aby uniwersalnie dostać punkt startu trzeba by najpierw ustalić czas 
lokalny gdy w Greenwich była północ nowego roku 1970. Cały czas jest ten 
sam problem do rozwiązania.

> Jak to c++, to pewnie warto przejrzeć, co jest w  std::chrono.
>

Zatrzymałem się w C++ na etapie, kiedy jeszcze nie było przestrzeni nazw.
Zebranie sobie w jakiejś przejrzystej formie wszystkich dostępnych 
funkcji dotyczących czasu chodzi za mną od dłuższego czasu :)
P.G.

W dniu 2017-03-24 o 15:34, Adam Wysocki pisze:
> Adam Wysocki <gof@somewhere.invalid> wrote:
>
>>> Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba
>>> przeliczać na sekundy uwzględniając lata przestępne itd.
>>
>> Może najpierw gmtime, a potem strftime z formatem %s?
>
> Lub gmtime i mktime.
>
Mam obawy, że mktime() powinno zamienić czas lokalny w struct tm na 
time_t, które wpisane stime() do zegara powinno być prawidłowym czasem 
dla zegara.
Jeśli w struct tm umieszczę czas Greenwich to pojęcia nie mam co mktime 
powinno mi wyliczyć :)

Wszystko byłoby jasne gdyby w zegarze i pobrany z niego funkcją time() 
czas był Greenwich.
Ale jeśli time() w Builderze C++ 5 daje o 1h inny czas niż w Builderze 
C++ 2010 to ....
Sądzę, że w zegarze jest czas Greenwich i time() w BC++ 5 pobiera go 
bezpośrednio, ale dlaczego Builder 2010 robi jakieś przesunięcie to ???

P.G.

W dniu 2017-03-24 o 15:34, Adam Wysocki pisze:
> Adam Wysocki <gof@somewhere.invalid> wrote:
>
>>> Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba
>>> przeliczać na sekundy uwzględniając lata przestępne itd.
>>
>> Może najpierw gmtime, a potem strftime z formatem %s?
>
> Lub gmtime i mktime.
>

Przeglądając tamten mój graf widzę jeszcze:
- między zegarem a struct date funkcję getdate().
- między zegarem a struct time funkcję gettime().
- między tymi dwiema strukturami a long funkcję dostounix().

Nie wiem czy te struktury mają po odczytaniu z zegara mieć czas lokalny, 
czy Greenwich.
Ciekawe, czy bez względu na to ta ścieżka prowadzi do czasu Greenwich.
Tylko nie podoba mi się wybieranie czasu dwiema funkcjami bo trzeba by 
się zabezpieczyć na wypadek jedno przed, a drugie po zmianie daty (nie 
napisałem po północy bo kto wie kiedy ta północ).
P.G.

On 24.03.2017 16:06, Piotr Gałka wrote:
> W dniu 2017-03-24 o 15:34, Adam Wysocki pisze:
>> Adam Wysocki <gof@somewhere.invalid> wrote:
>>
>>>> Rzuciłem okiem na gmtime, ale to daje strukturę, którą by trzeba
>>>> przeliczać na sekundy uwzględniając lata przestępne itd.
>>>
>>> Może najpierw gmtime, a potem strftime z formatem %s?
>>
>> Lub gmtime i mktime.
>>
>
> Przeglądając tamten mój graf widzę jeszcze:
> - między zegarem a struct date funkcję getdate().
> - między zegarem a struct time funkcję gettime().

Skad są te dwie ostatnie funkcje?

> - między tymi dwiema strukturami a long funkcję dostounix().
>
> Nie wiem czy te struktury mają po odczytaniu z zegara mieć czas lokalny,
> czy Greenwich.


Ja to zrozumiałęm tak, że
time()
trzyma czas w jakiej swoim ulubionym formacie, nieznanym w ogolności
dla piszącego. Możę to być unixtime, może być to filetime.
time_t można przerobić na coś czytelnego funbkcjami
gmtime i localtime. One są już odpowiednio w UTC i czasie lokalnym.

Samo time_t nie jest w żadnej strefie, to to liczba jednostek czasu
od ustalonej chwili. Dopiero gmtime, localtime czy ctime (też czas
loklany) zamieniają je dna date/godzinę wyrażoną w danej strefie.



> Ciekawe, czy bez względu na to ta ścieżka prowadzi do czasu Greenwich.
> Tylko nie podoba mi się wybieranie czasu dwiema funkcjami bo trzeba by
> się zabezpieczyć na wypadek jedno przed, a drugie po zmianie daty (nie
> napisałem po północy bo kto wie kiedy ta północ).

?

a co jest złego w styrukturze tm? Ona ma wszystko, godzine, date,
dzień tygodnia, dzień roku...

z difftime bedzie dzialać jak oczekujesz, tylko aby wszystko domknac,
trzeba by umiec generować time_t dla chwili, który uznajesz
za umowny poczatek. I nie wiem czym, bo mktime konwerteuje godzinodatę
uznajac, ze jest ona w czasie lokalnym.

BTW, tu lista co siedzi na pewno w time.h
http://en.cppreference.com/w/c/chrono
i tam jest
http://en.cppreference.com/w/c/chrono/timespec_get
i przynajmniej wyciąfać czasy z roznych stref jest ciut wygodniej.




http://en.cppreference.com/w/cpp/chrono/time_point
Na zachętę:
http://en.cppreference.com/w/cpp/chrono/time_point/time_since_epoch

Ale zawartość chrono zawsze wywoluje u mnie mętlik w głowie.
OK, jest to wzytko logiczne i przydatne, ale jest tego za dużo
jak na uwagę, jaką zwykle do tego przywiązuuyję ;-)

pzdr
bartekltg

W dniu 2017-03-24 o 20:01, bartekltg pisze:
>>
>> Przeglądając tamten mój graf widzę jeszcze:
>> - między zegarem a struct date funkcję getdate().
>> - między zegarem a struct time funkcję gettime().
>
> Skad są te dwie ostatnie funkcje?

<dos.h>

>> - między tymi dwiema strukturami a long funkcję dostounix().

ta też tam.

> Ja to zrozumiałęm tak, że
> time()
> trzyma czas w jakiej swoim ulubionym formacie, nieznanym w ogolności
> dla piszącego. Możę to być unixtime, może być to filetime.
> time_t można przerobić na coś czytelnego funbkcjami
> gmtime i localtime. One są już odpowiednio w UTC i czasie lokalnym.

Ten opis time() który wcześniej zacytowałeś jest sprzeczny z tym, który 
ja znam (z helpa Buildera 5):
"time gives the current time, in seconds, elapsed since 00:00:00 GMT, 
January 1, 1970, and stores that value in the location pointed to by 
timet, provided that timer is not a NULL pointer."
Dlatego zdziwiłem się, że coś, co dla mnie chyba gdzieś od lat 80-tych 
było oczywiste nagle mi nie działa.
Używam tylko dwóch kompilatorów Buildera-5 - ma bardzo dobry help - 
zawsze trafia w to czego szukam (z wyjątkiem strumieni).
Buildera 2010 - prawie nic w helpie nie idzie znaleźć - mi chodzi o 
jakąś funkcję, a on (chyba nie znajdując) otwiera mi help na temat 
używania Edytora.
Dlatego opieram się na tym co znajduję w Builderze-5.

>> Ciekawe, czy bez względu na to ta ścieżka prowadzi do czasu Greenwich.
>> Tylko nie podoba mi się wybieranie czasu dwiema funkcjami bo trzeba by
>> się zabezpieczyć na wypadek jedno przed, a drugie po zmianie daty (nie
>> napisałem po północy bo kto wie kiedy ta północ).
>
> ?
Jak jedno pobiorę z zegara przed zmianą doby, a drugie po to będę miał 
błąd o dobę, a ta uwaga w nawiasie chyba faktycznie nie ma sensu.

>
> a co jest złego w styrukturze tm? Ona ma wszystko, godzine, date,
> dzień tygodnia, dzień roku...
>
A do czego miała by się przydać. difftime potrzebuje time_t.
Nie ma sensu zamieniać time_t na tm i z powrotem na time_t.


> z difftime bedzie dzialać jak oczekujesz, tylko aby wszystko domknac,
> trzeba by umiec generować time_t dla chwili, który uznajesz
> za umowny poczatek. I nie wiem czym, bo mktime konwerteuje godzinodatę
> uznajac, ze jest ona w czasie lokalnym.

I tu mi wychodzi, że tm nic nie daje.

> BTW, tu lista co siedzi na pewno w time.h
> http://en.cppreference.com/w/c/chrono

Jak wszedłem w time to w przykładzie zakładają, ze time_t custed do 
uintmax_t daje czas w sekundach od Epoch czyli jak rozumiem GMT.

time() (pod Builderem 2010) przed zmianą czasu dawało mi błąd o 1h 
względem GMT a teraz daje mi dobry czas.

Cast (uintmax_t) z wartości odczytanej time() działa tak samo - czyli 
dziś dobrze, ale w zimie źle (cofnąłem zegar komputera).

Natomiast GetSystemTimeAsFileTime() działa mi dobrze i teraz i w zimie.


> i tam jest
> http://en.cppreference.com/w/c/chrono/timespec_get
> i przynajmniej wyciąfać czasy z roznych stref jest ciut wygodniej.
>

Tam jest taki fragment:
------------
If base is TIME_UTC, then
ts->tv_sec is set to the number of seconds since an implementation 
defined epoch,
------------

Mi to sugeruje, że nawet jak bazę wpiszę na TIME_UTC to dostanę coś 
implementation defined.

> http://en.cppreference.com/w/cpp/chrono/time_point
> Na zachętę:
> http://en.cppreference.com/w/cpp/chrono/time_point/time_since_epoch
>
> Ale zawartość chrono zawsze wywoluje u mnie mętlik w głowie.

Nie jestem na bieżąco z nowinkami - to co pokazujesz jest od C11, a ja 
używam narzędzi sprzed C11.

Wydaje mi się, że tak jak było opisane w Builderze 5 - czyli time() daje 
czas GMT było dobrze.
Jedynie można było zmienić time_t z long na unsigned long, albo unsigned 
long long.

Mam wrażenie, że coś prostego zostało skutecznie zagmatwane.
Aż dziwne, że aby uzyskać GMT (w sekundach) to trzeba przechodzić przez 
jakieś struktury.

> OK, jest to wzytko logiczne i przydatne, ale jest tego za dużo
> jak na uwagę, jaką zwykle do tego przywiązuuyję ;-)
>
Jeszcze nigdy nie przyglądałem się zawartości chrono. Jak zacznę używać 
czegoś C11 to się (może) przyjrzę.
P.G.

On 27.03.2017 13:51, Piotr Gałka wrote:
> W dniu 2017-03-24 o 20:01, bartekltg pisze:
>>>
>>> Przeglądając tamten mój graf widzę jeszcze:
>>> - między zegarem a struct date funkcję getdate().
>>> - między zegarem a struct time funkcję gettime().
>>
>> Skad są te dwie ostatnie funkcje?
>
> <dos.h>
>
>>> - między tymi dwiema strukturami a long funkcję dostounix().
>
> ta też tam.
>
>> Ja to zrozumiałęm tak, że
>> time()
>> trzyma czas w jakiej swoim ulubionym formacie, nieznanym w ogolności
>> dla piszącego. Możę to być unixtime, może być to filetime.
>> time_t można przerobić na coś czytelnego funbkcjami
>> gmtime i localtime. One są już odpowiednio w UTC i czasie lokalnym.
>
> Ten opis time() który wcześniej zacytowałeś jest sprzeczny z tym, który
> ja znam (z helpa Buildera 5):
> "time gives the current time, in seconds, elapsed since 00:00:00 GMT,
> January 1, 1970, and stores that value in the location pointed to by
> timet, provided that timer is not a NULL pointer."

Gdzie tu widzisz sprzeczność.

Opis ogolny mowi, żę jest to zalezne od implementacji, i jako
ciekawostke podaje, że czesto jest to unix time.

Dokumentacja Buildera 5 dla tego a tego systemu podaje, że
jest to zamiplementowane _w builderze 5_ tak a tak.

Skoro inna wersja buildera działała inaczej, to pewnie w dokumentacji
do odpowiedniej wersji programu jest też to napisane.
Albo mają w dokumentacji błąd ;-)

> Dlatego zdziwiłem się, że coś, co dla mnie chyba gdzieś od lat 80-tych
> było oczywiste nagle mi nie działa.

Od 95 windows używa innego zapisu czasu. Dos (czyli też np windows 3.11)
używał jeszcze innego.

Nie ma w tym nic oczywistego ;-)

> Używam tylko dwóch kompilatorów Buildera-5 - ma bardzo dobry help -
> zawsze trafia w to czego szukam (z wyjątkiem strumieni).
> Buildera 2010 - prawie nic w helpie nie idzie znaleźć - mi chodzi o

Pewnie uznbali, że ludize i tak korzystają z ulubionej wersji
dokumentacji _języka_ online. A, że wiekszość kompilatorów
implementuje diś standard, nie własną wersję, to mogli uznać,
że szkoda pracy ludzi na dołaczanie opisu języka.

Dokumentacja do VCL i innych ich bibliotek na stronie jest.

Jeśli brakuje Ci dokumentacji do standardowej cześći, pisz im,
płacącego klienta (jeśli będize ich dużo) mogą posłuchać;-)

> jakąś funkcję, a on (chyba nie znajdując) otwiera mi help na temat
> używania Edytora.
> Dlatego opieram się na tym co znajduję w Builderze-5.

Ale pewne rzeczy opisane w tej dokumentacji dotyczą implementacji
w B5, a ogolnie są dowolne. I teraz Builder 10 na windowsie
użyje filetime. (a na linuxie pewnie unixtime ;-))
Dokumentacja dla wersji sprzed 5 lat wcześniej nie jest dla nich
wiążąca.

Choć to koszmarny zwyczaj! Jakby dali od poczatku 'zależy od
implementacji' to wiadomo by było, że trzeba pisać tak, aby nie
korzystać z wiedzy, w jakim formacie jest time_t.
A tak obiecali unixtime, a potem zmienili i popsuli stary kod wielu
ludziom ;-]



BTW, od 2005 nie tylko w C++, ale i w C pojawiło się trochę nowych
przydatnych rzeczy.

>>> Ciekawe, czy bez względu na to ta ścieżka prowadzi do czasu Greenwich.
>>> Tylko nie podoba mi się wybieranie czasu dwiema funkcjami bo trzeba by
>>> się zabezpieczyć na wypadek jedno przed, a drugie po zmianie daty (nie
>>> napisałem po północy bo kto wie kiedy ta północ).
>>
>> ?
> Jak jedno pobiorę z zegara przed zmianą doby, a drugie po to będę miał
> błąd o dobę,

A, OK, myślałem, żę getdate() i gettime() dekodują czas ze zmiennej,
a one go odczytują z zegara.

Zgoda, bzdurne funkcje, nie używaj ich.


>> a co jest złego w styrukturze tm? Ona ma wszystko, godzine, date,
>> dzień tygodnia, dzień roku...
>>
> A do czego miała by się przydać.

?
Do tego samego, do czego para
getdate() i gettime().
Aby dostać godzinę i datę ;-)

I to tym razem dostajesz bez wymeinionyhc wcześneij problemów.

> difftime potrzebuje time_t.
> Nie ma sensu zamieniać time_t na tm i z powrotem na time_t.

A po co miałbyś to robić?

Chciałeś zmierzyć czas w sekundach pomiędzy dwoma momentami.
difftime jest do tego odpowiednią standardową funkcją.


>> z difftime bedzie dzialać jak oczekujesz, tylko aby wszystko domknac,
>> trzeba by umiec generować time_t dla chwili, który uznajesz
>> za umowny poczatek. I nie wiem czym, bo mktime konwerteuje godzinodatę
>> uznajac, ze jest ona w czasie lokalnym.
>
> I tu mi wychodzi, że tm nic nie daje.

Bo?

W sumie nigdy nie powqiedziałeś, co tak naprawdę chcesz osiagnać.


>> BTW, tu lista co siedzi na pewno w time.h
>> http://en.cppreference.com/w/c/chrono
>
> Jak wszedłem w time to w przykładzie zakładają, ze time_t custed do
> uintmax_t daje czas w sekundach od Epoch czyli jak rozumiem GMT.

Nie.

Przeczytaj raz jeszcze.

#include <stdio.h>
#include <time.h>
#include <stdint.h>

int main(void)
{
     time_t result = time(NULL);
     if(result != -1)
         printf("The current time is %s(%ju seconds since the Epoch)\n",
                asctime(gmtime(&result)), (uintmax_t)result);
}

Possible output:
The current time is Fri Apr 24 15:05:25 2015
(1429887925 seconds since the Epoch)

Gdzie tu jest założenie o formacie time_t poza tym, zę jest on
w sekundach?
Wypluta liczba 1429887925 zależy od implementacji, bo epoka
możę być inaczej ustalona.


> time() (pod Builderem 2010) przed zmianą czasu dawało mi błąd o 1h
> względem GMT a teraz daje mi dobry czas.

Może miałeś zegar źle skonfigurowany? ;-)

BTW, time_t to nie czas. To liczba sekund od chwili
takiej a takiej tego a tego dnia w takiej a takeij strefie.
Przeliczałeś to poprawnie? Inną liczbę godzin trzeba przesunac
zimą i latem.


> Cast (uintmax_t) z wartości odczytanej time() działa tak samo - czyli
> dziś dobrze, ale w zimie źle (cofnąłem zegar komputera).

Ale Ty nie masz cofnąć zegara. Masz kliknąć 'czas letni/zimowy',
bo to NIE jest to samo co cofnać zegar.


> Natomiast GetSystemTimeAsFileTime() działa mi dobrze i teraz i w zimie.



>> i tam jest
>> http://en.cppreference.com/w/c/chrono/timespec_get
>> i przynajmniej wyciąfać czasy z roznych stref jest ciut wygodniej.
>>
>
> Tam jest taki fragment:
> ------------
> If base is TIME_UTC, then
> ts->tv_sec is set to the number of seconds since an implementation
> defined epoch,
> ------------
>
> Mi to sugeruje, że nawet jak bazę wpiszę na TIME_UTC to dostanę coś
> implementation defined.

Tak.

Pomyśl w ten sposób, co Cię obchoedzi epoka? Co za różnica dla pisacego,
czy liczą sekundy od 1601, 1970, 1980 czy 1900?

Obchodzi Cię transformacja time_t <-> data/godzina, która też jest 
odpowiednio zdefiniowana,
i różnica pomiędzy dwoma time_t (bo wtedy epoka się skasuje... ale i tak
lepiej użyć difftime).


>> http://en.cppreference.com/w/cpp/chrono/time_point
>> Na zachętę:
>> http://en.cppreference.com/w/cpp/chrono/time_point/time_since_epoch
>>
>> Ale zawartość chrono zawsze wywoluje u mnie mętlik w głowie.
>
> Nie jestem na bieżąco z nowinkami - to co pokazujesz jest od C11, a ja
> używam narzędzi sprzed C11.

Po co sobie życie utrudniać?
;-)


> Wydaje mi się, że tak jak było opisane w Builderze 5 - czyli time() daje
> czas GMT było dobrze.

Ale w windowsie system nie daje posixowego czasu. Daje windowsowy.
Można to przeliczać w time(.), ale po co mieliby to robić?

> Jedynie można było zmienić time_t z long na unsigned long, albo unsigned
> long long.

Nie powinno Cię obchodzić, jakiego typu jest time_t.
CHyba nawet nie jest powiedziane, zę ma być to typ całkowity ;-)


> Mam wrażenie, że coś prostego zostało skutecznie zagmatwane.
> Aż dziwne, że aby uzyskać GMT (w sekundach) to trzeba przechodzić przez
> jakieś struktury.

Nie ma czegoś takiego jak GMT w sekundach.

GTM w sekundach od określonej chwili czasu, generowany
przenośnie, nie jest takim oczywistym i każdemu potrzebnym
narzędziem ;-)
A i wtedy, są to trzy-czytery linijki.


>> OK, jest to wzytko logiczne i przydatne, ale jest tego za dużo
>> jak na uwagę, jaką zwykle do tego przywiązuuyję ;-)
>>
> Jeszcze nigdy nie przyglądałem się zawartości chrono. Jak zacznę używać
> czegoś C11 to się (może) przyjrzę.

Chrono jest w c++11. Czy jest jakiś odpowiendik w C11, głęboko wątpię.

pzdr
bartekltg

W dniu 2017-03-27 o 15:56, bartekltg pisze:
>
> Gdzie tu widzisz sprzeczność.
>
> Opis ogolny mowi, żę jest to zalezne od implementacji, i jako
> ciekawostke podaje, że czesto jest to unix time.
>
> Dokumentacja Buildera 5 dla tego a tego systemu podaje, że
> jest to zamiplementowane _w builderze 5_ tak a tak.
>
Precyzyjnie rozumując faktycznie masz rację.
Ja po prostu przyjąłem, że opis standardowych funkcji bibliotecznych 
jest uniwersalny, a nie tylko dla danej implementacji.

W książkowej dokumentacji Buildera 5 ta funkcja jest dokładnie tak 
opisana jak napisałem i dodatkowo jest tabelka w jakich systemach działa 
tak samo (DOS, UNIX, Win 16, Win 32, ANSI C, ANSI C++, OS/2).
Zapamiętałem to jako "wszędzie działa tak samo".
A ja mam Win 64 i nie ANSI C++ - czyli nie mogę się czepiać :)

Wygląda na to, że powinienem podejrzliwie podchodzić do każdej funkcji, 
bo może np. memcpy() teraz też inaczej działa :)

> Dokumentacja do VCL i innych ich bibliotek na stronie jest.

Przyzwyczajenie drugą naturą człowieka. Więcej pisałem w latach 85-95, 
gdy nie było dokumentacji na stronie. Teraz, jak bardzo sporadycznie coś 
muszę napisać to .... nie przestawiłem się na korzystanie z dokumentacji 
znajdującej się 'gdzieś tam'.

>>> a co jest złego w styrukturze tm? Ona ma wszystko, godzine, date,
>>> dzień tygodnia, dzień roku...
>>>
>> A do czego miała by się przydać.
>
> ?
> Do tego samego, do czego para
> getdate() i gettime().
> Aby dostać godzinę i datę ;-)
>
> I to tym razem dostajesz bez wymeinionyhc wcześneij problemów.
>
>> difftime potrzebuje time_t.
>> Nie ma sensu zamieniać time_t na tm i z powrotem na time_t.
>
> A po co miałbyś to robić?

Coś się tu nie rozumiemy.
Pisząc nie szukam info w necie, więc mogę czegoś nie wiedzieć.
Dla mnie tm to struktura, którą mogę wypełnić aktualnym czasem za pomocą 
funkcji localtime() na podstawie time_t (odczytanej z zegara funkcją 
time()).

Sugerujesz użycie tm i difftime aby znaleźć ten czas GMT.
difftime przyjmuje time_t. Nie muszę aktualnego czasu mieć w postaci tm 
jak już go mam w time_t.

Gdybym wiedział co wpisać w tm aby funkcją mktime dostać time_t 
odpowiadające GMT godziny 0:00 1.1.1970 - miałbyś rację, ale nie wiem.


> Chciałeś zmierzyć czas w sekundach pomiędzy dwoma momentami.
> difftime jest do tego odpowiednią standardową funkcją.
>
Ale nie znam zapisu tego początkowego momentu i nie bardzo widzę jak 
miałbym go uzyskać skoro wartość time_t jest zależna od implementacji.

>> I tu mi wychodzi, że tm nic nie daje.
>
> Bo?
j.w.

>
> W sumie nigdy nie powqiedziałeś, co tak naprawdę chcesz osiagnać.
>
Cytat z mojej pierwszej wypowiedzi:
"Mój problem - chcę pod Builderem 2010 dostać aktualny czas Greenwich w 
formacie Unix."
Może to nie jest precyzyjne określenie - chodzi o czas w sekundach tak 
jak jest dostarczany przez internetowe serwery czasu.

Chodziło o poprawkę w programie, który (jak był napisany) działał 
dobrze, a potem (zima) zaczął wpisywać zły czas. Program jest używany 
sporadycznie.

Ja już to zrobiłem (tym GetSystem........tralala), a dyskutuję dalej bo 
uważam, że rozbieżności wypada wyjaśnić, a nie uszy po sobie i "nie ma 
mnie".


>
>>> BTW, tu lista co siedzi na pewno w time.h
>>> http://en.cppreference.com/w/c/chrono
>>
>> Jak wszedłem w time to w przykładzie zakładają, ze time_t custed do
>> uintmax_t daje czas w sekundach od Epoch czyli jak rozumiem GMT.
>
> Nie.
>
> Przeczytaj raz jeszcze.
>
> #include <stdio.h>
> #include <time.h>
> #include <stdint.h>
>
> int main(void)
> {
>     time_t result = time(NULL);
>     if(result != -1)
>         printf("The current time is %s(%ju seconds since the Epoch)\n",
>                asctime(gmtime(&result)), (uintmax_t)result);
> }
>
> Possible output:
> The current time is Fri Apr 24 15:05:25 2015
> (1429887925 seconds since the Epoch)
>
> Gdzie tu jest założenie o formacie time_t poza tym, zę jest on
> w sekundach?
> Wypluta liczba 1429887925 zależy od implementacji, bo epoka
> możę być inaczej ustalona.

Dla mnie "seconds since the Epoch" oznacza, że to są zawsze sekundy od 
pewnego konkretnego momentu czasu.

Problem na który się natknąłem (Builder 2010):
Czas zimowy: u nas godzina 12, GMT godzina 11, time() daje godz 10.
Czas letni : u nas godzina 13, GMT godzina 11, time() daje godz 11.

Skoro dla tej samej godziny GMT (a ten czas nie ma skoków lato/zima) z 
time() wychodzi inna godzina to znaczy, że nie jest on liczony od 
jakiegoś konkretnego momentu Epoch, tylko jest jakoś inaczej 
implementation dependent (co się zgadza z opisem time(), który 
przytoczyłeś na początku, ale nie zgadza się z tym opisem który teraz tu 
zacytowałeś).

>> time() (pod Builderem 2010) przed zmianą czasu dawało mi błąd o 1h
>> względem GMT a teraz daje mi dobry czas.
>
> Może miałeś zegar źle skonfigurowany? ;-)

Zegar się sam konfiguruje i sam przestawia czas letni/zimowy.


> BTW, time_t to nie czas. To liczba sekund od chwili
> takiej a takiej tego a tego dnia w takiej a takeij strefie.
> Przeliczałeś to poprawnie? Inną liczbę godzin trzeba przesunac
> zimą i latem.

Ale ja nie próbuję dostać naszego czasu tylko GMT. Ten się nie zmienia 
lato/zima.

> Ale Ty nie masz cofnąć zegara. Masz kliknąć 'czas letni/zimowy',
> bo to NIE jest to samo co cofnać zegar.

Jak cofam zegar to on sam wie czy czas letni, czy zimowy i po to 
cofnąłem aby znowu znaleźć się w zimie.
Program zachowywał się dokładnie tak samo jak w zeszłym tygodniu.


> Pomyśl w ten sposób, co Cię obchoedzi epoka? Co za różnica dla pisacego,
> czy liczą sekundy od 1601, 1970, 1980 czy 1900?
>

Dla piszącego (kogokolwiek to oznacza) może nie ma różnicy, ale dla mnie 
jest.
Urządzenie normalnie pobiera sobie czas z internetowych serwerów czasu - 
dostaje czas GMT w sekundach od 1.1.1970.
Gdy urządzenie nie ma dostępu do sieci mam mu podać ten czas z komputera 
w takim samym formacie.

> Obchodzi Cię transformacja time_t <-> data/godzina, która też jest
> odpowiednio zdefiniowana,
> i różnica pomiędzy dwoma time_t (bo wtedy epoka się skasuje... ale i tak
> lepiej użyć difftime).

Wmawiasz mi, że obchodzi mnie coś, co mnie nie obchodzi.

> Nie powinno Cię obchodzić, jakiego typu jest time_t.
> CHyba nawet nie jest powiedziane, zę ma być to typ całkowity ;-)
>
Fakt, ale powinien być jakiś prosty sposób dostania z time_t czasu GMT 
wyrażonego w sekundach od dowolnego, ale stałego momentu.

> GTM w sekundach od określonej chwili czasu, generowany
> przenośnie, nie jest takim oczywistym i każdemu potrzebnym
> narzędziem ;-)
> A i wtedy, są to trzy-czytery linijki.
>
Napisz te 4 linijki (bazując na time()).
Mam podejrzenie, że pod Builderem-5 będzie ok, a pod 2010 będzie źle.
Sprawdzę.

> Chrono jest w c++11. Czy jest jakiś odpowiendik w C11, głęboko wątpię.

Miałem na myśli C++11.
P.G.