freemint-discuss — The official FreeMiNT Mailing List

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[David G. <dga...@gm...>]

2018-08-05 18:54 GMT+02:00 Peter Slegg <p....@sc...>:
> Thanks. I had assumed it was for tzinit.
>
> I tried calling ntpdate before tzinit but it still shows GMT.
>
> So from bash I tried various combinations.
> The time is currently 17:50 BST but it only shows 16:50 or 15:50
>
>
> Test with tzinit -u
>
> bash-4.3# date
> Sun Aug  5 16:51:27 BST 2018
>
> bash-4.3# ntpdate pool.ntp.org
> Looking for host pool.ntp.org and service ntp
> host found : fluffykins.positive-internet.com
>  5 Aug 16:51:32 ntpdate[205]: step time server 80.87.128.222 offset 3600.563846 sec
>
> bash-4.3# date
> Sun Aug  5 16:51:34 BST 2018
>
> bash-4.3# /sbin/tzinit -u
> Current date and time: Sun Aug  5 16:51:41 2018
> Time zone in use: BST
> East of Greenwich Mean Time: 1:00:00
> Kernel clock mode: UTC
>
> bash-4.3# date
> Sun Aug  5 16:51:42 BST 2018
>
>
>
> Test with tzinit -l
>
> bash-4.3# date
> Sun Aug  5 16:52:27 BST 2018
>
> bash-4.3# /sbin/tzinit -l
> Current date and time: Sun Aug  5 15:52:39 2018
> Time zone in use: BST
> East of Greenwich Mean Time: 1:00:00
> Kernel clock mode: localtime
>
> bash-4.3# date
> Sun Aug  5 15:52:46 BST 2018
>
> bash-4.3# ntpdate pool.ntp.org
> Looking for host pool.ntp.org and service ntp
> host found : time.rdg.uk.as44574.net
>  5 Aug 16:52:52 ntpdate[212]: step time server 193.150.34.2 offset 7200.727898 sec
>
> bash-4.3# date
> Sun Aug  5 16:52:54 BST 2018
>

Can you comment/remove the line where TZ variable is set in mint.cnf
and try again?
Show us please the output of date, tzinit and ntpdate after the
variable is unset.

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 05 Aug 2018 18:34:13 , Thorsten Otto <ad...@th...> wrote:
> On Sonntag, 5. August 2018 18:27:17 CEST Peter Slegg wrote:
> > What is TZ for ?
>
> TZ is for older libraries like the one from PureC that don't have a timezone
> database.
>
>
Thanks. I had assumed it was for tzinit.

I tried calling ntpdate before tzinit but it still shows GMT.

So from bash I tried various combinations.
The time is currently 17:50 BST but it only shows 16:50 or 15:50


Test with tzinit -u

bash-4.3# date
Sun Aug  5 16:51:27 BST 2018

bash-4.3# ntpdate pool.ntp.org
Looking for host pool.ntp.org and service ntp
host found : fluffykins.positive-internet.com
 5 Aug 16:51:32 ntpdate[205]: step time server 80.87.128.222 offset 3600.563846 sec

bash-4.3# date
Sun Aug  5 16:51:34 BST 2018

bash-4.3# /sbin/tzinit -u
Current date and time: Sun Aug  5 16:51:41 2018
Time zone in use: BST
East of Greenwich Mean Time: 1:00:00
Kernel clock mode: UTC

bash-4.3# date
Sun Aug  5 16:51:42 BST 2018



Test with tzinit -l

bash-4.3# date
Sun Aug  5 16:52:27 BST 2018

bash-4.3# /sbin/tzinit -l
Current date and time: Sun Aug  5 15:52:39 2018
Time zone in use: BST
East of Greenwich Mean Time: 1:00:00
Kernel clock mode: localtime

bash-4.3# date
Sun Aug  5 15:52:46 BST 2018

bash-4.3# ntpdate pool.ntp.org
Looking for host pool.ntp.org and service ntp
host found : time.rdg.uk.as44574.net
 5 Aug 16:52:52 ntpdate[212]: step time server 193.150.34.2 offset 7200.727898 sec

bash-4.3# date
Sun Aug  5 16:52:54 BST 2018



Peter

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Thorsten O. <ad...@th...>]

On Sonntag, 5. August 2018 18:27:17 CEST Peter Slegg wrote:
> What is TZ for ?

TZ is for older libraries like the one from PureC that don't have a timezone 
database.

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 5 Aug 2018 15:31:10 , Peter Slegg <p....@sc...> wrote:
> On Sun, 05 Aug 2018 16:54:17 , Thorsten Otto <ad...@th...> wrote:
> > On Sonntag, 5. August 2018 16:47:23 CEST Peter Slegg wrote:
> > > I assume TZ GB should alter the time on the correct date ?
> >
> > tzinit does not care about the TZ environment variable. You have to copy or
> > link the correct file from /usr/share/zoneinfo/* to /etc/localtime
> >
> >
>
>
> The localtime file is a link
>
> lrwxrwxrwx    1 root     root           29 May  1  2016 localtime -> /usr/share/zoneinfo/Factory
>
>
> Peter
>


I changed the link to use London but it is still shoiwng GMT time

bash-4.3# date
Sun Aug  5 15:43:02 BST 2018


What is TZ for ?

Peter

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 05 Aug 2018 16:54:17 , Thorsten Otto <ad...@th...> wrote:
> On Sonntag, 5. August 2018 16:47:23 CEST Peter Slegg wrote:
> > I assume TZ GB should alter the time on the correct date ?
>
> tzinit does not care about the TZ environment variable. You have to copy or
> link the correct file from /usr/share/zoneinfo/* to /etc/localtime
>
>


The localtime file is a link

lrwxrwxrwx    1 root     root           29 May  1  2016 localtime -> /usr/share/zoneinfo/Factory


Peter

[Freemint-discuss] Mangled message

[Roger B. <an...@xp...>]

The most recent message from Peter Slegg got mangled somehow, so I had to 
approve its posting, which I did.  However the header is screwed up, so the 
"From" & "Subject" are useless.  Apologies, it's outside my control.

Roger

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Thorsten O. <ad...@th...>]

On Sonntag, 5. August 2018 16:47:23 CEST Peter Slegg wrote:
> I assume TZ GB should alter the time on the correct date ?

tzinit does not care about the TZ environment variable. You have to copy or 
link the correct file from /usr/share/zoneinfo/* to /etc/localtime

Re: [Freemint-discuss] Installation path for shared libs

[Thorsten O. <ad...@th...>]

On Sonntag, 5. August 2018 13:52:47 CEST Miro Kropáček wrote:
> applications like "setup.app" from various software packages (aniplayer
> comes to my mind) simply copy all *.slb into given directory.

Yes, but having a to write a "setup.app" would be extra effort. Also i'm 
currently speaking about more standard libraries like zlib and pnglib that are 
not specific to a single application (i just wonder that apparently nobody has 
built such things yet).

>To make this totally right I'd say FreeMiNT would need to look after 
>$SLBPATH/$CPU in addition to just $SLBPATH, very similar what mintloader.prg 
>does for freemint modules ($SYSDIR + $SYSDIR/<machine specific folder>). 

That would make sense. But of course that currently does not help much 
currently as long as this is not implemented.

[Freemint-discuss] (no subject)

    <ad...@th...>
Cc: <fre...@li...>
From: Peter Slegg <p....@sc...>
Subject: Re: [Freemint-discuss] Installation path for shared libs
Reply-To: Peter Slegg <p....@sc...>
X-Mailer: MyMAIL Rev:1.96.04.14145 (Atari/(STiK/STinG/GlueSTiK))
X-Hardware: Atari Milan
MIME-Version: 1.0
Date: Sun, 5 Aug 2018 14:50:16 +0000 (GMT)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <000...@sm...>
References: <CAN...@ma...>
In-Reply-To: CAN...@ma...

Mine are in C:\GEMSYS\SLB

This is because I had Magic on my STfm and I copied the same config
onto my Milan even though it never had Magic on it.


Peter



On Sun, 5 Aug 2018 13:52:47 , Miro Krop=E1?ek wrote:

Yes, those are very good questions.
I would say /mint/slb (and its MagiC counter part /gemsys/magic/xtension)
and /gemsys/ldg are indeed a de facto standard but it doesn't answer your
concern about different CPU builds.
On the other hand, there really isn't any real world scenario (as of yet)
requiring the user to care about it -- applications like "setup.app" from
various software packages (aniplayer comes to my mind) simply copy all
*.slb into given directory. Different CPU builds are solved via setup.app -
you can choose your favourite CPU build but only one.
So if the user knows that all his SLBs are in some directory, he would just
copy new SLB there, either automatically (setup.app) or manually.
To make this totally right I'd say FreeMiNT would need to look after
$SLBPATH/$CPU in addition to just $SLBPATH, very similar what
mintloader.prg does for freemint modules ($SYSDIR + $SYSDIR/<machine
specific folder>). And in that case we can come up with any naming scheme
we like - m68000, m6802060, m5475, ... but it doesn't look like a priority
to me.
On Sun, 5 Aug 2018 at 04:07, Thorsten Otto <ad...@th...> wrote:
> Not that these are currently used much in FreeMinT (i think the recently
> added
> gemma.slb is the only one), but is there some standard/convention where to
> install shared libraries (the actual code that is loaded by Slbopen(), not
> any
> helper libraries you might need in your application).
>
> The automatic build process currently does not install them i think (only
> the
> development parts). And in the Makefile of eg. gemma, when you do a "make
> install", it will be installed to /mint/slb, and cpu-specific
> subdirectories.
>
> The question is: is that base-directory more or less standard? I've also
> seen
> pathes like /gemsys/slb, and  in MagiC they are usually in installed in /
> gemsys/magic/xtension.
>
> Also the names of the cpu-specific sub-directories are questionable.
> Currently
> the same names as the multi-lib directories from gcc are used (m68020-60,
> m5475 etc.). Since /mint (or /gemsys) are usually on the boot partition,
> and
> thus on a FAT filesystem, at least m68020-60 is not the best choice.
>
> And then: should the default libs (for plain 68000) be installed in the
> base
> directory, or also in a dedicated sub-directory, like the others? That
> would
> make it easier to switch configurations by just setting SLBPATH
> accordingly,
> without having to copy around actual files.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>
--
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 5 Aug 2018 10:59:46 , David Gálvez wrote:
> 2018-08-04 22:52 GMT+02:00 Peter Slegg <p....@sc...>:
> > I did have ntpdate in mint.cnf but it seems to have gone from the
> > mint.cnf files in all the folders !
> >
> > Last year I was trying to get ntpd working, so maybe I removed it then.
> >
> > I have put ntpdate back again.
> >
> > # Timezone (mandatory)
> > #~setenv TZ GMT-0BST,3.5.0,10.5.0
> > setenv TZ GB
> > #exec    u:\sbin\tzinit -l
> > exec    u:\sbin\tzinit -u
> > ntpdate pool.ntp.org
> >
>
> Do you have now the right time?
>

No, it's still showing GMT when I think it should be showing BST.
I assume TZ GB should alter the time on the correct date ?

Peter

Re: [Freemint-discuss] Installation path for shared libs

[Miro K. <mir...@gm...>]

Yes, those are very good questions.

I would say /mint/slb (and its MagiC counter part /gemsys/magic/xtension)
and /gemsys/ldg are indeed a de facto standard but it doesn't answer your
concern about different CPU builds.

On the other hand, there really isn't any real world scenario (as of yet)
requiring the user to care about it -- applications like "setup.app" from
various software packages (aniplayer comes to my mind) simply copy all
*.slb into given directory. Different CPU builds are solved via setup.app -
you can choose your favourite CPU build but only one.

So if the user knows that all his SLBs are in some directory, he would just
copy new SLB there, either automatically (setup.app) or manually.

To make this totally right I'd say FreeMiNT would need to look after
$SLBPATH/$CPU in addition to just $SLBPATH, very similar what
mintloader.prg does for freemint modules ($SYSDIR + $SYSDIR/<machine
specific folder>). And in that case we can come up with any naming scheme
we like - m68000, m6802060, m5475, ... but it doesn't look like a priority
to me.

On Sun, 5 Aug 2018 at 04:07, Thorsten Otto <ad...@th...> wrote:

> Not that these are currently used much in FreeMinT (i think the recently
> added
> gemma.slb is the only one), but is there some standard/convention where to
> install shared libraries (the actual code that is loaded by Slbopen(), not
> any
> helper libraries you might need in your application).
>
> The automatic build process currently does not install them i think (only
> the
> development parts). And in the Makefile of eg. gemma, when you do a "make
> install", it will be installed to /mint/slb, and cpu-specific
> subdirectories.
>
> The question is: is that base-directory more or less standard? I've also
> seen
> pathes like /gemsys/slb, and  in MagiC they are usually in installed in /
> gemsys/magic/xtension.
>
> Also the names of the cpu-specific sub-directories are questionable.
> Currently
> the same names as the multi-lib directories from gcc are used (m68020-60,
> m5475 etc.). Since /mint (or /gemsys) are usually on the boot partition,
> and
> thus on a FAT filesystem, at least m68020-60 is not the best choice.
>
> And then: should the default libs (for plain 68000) be installed in the
> base
> directory, or also in a dedicated sub-directory, like the others? That
> would
> make it easier to switch configurations by just setting SLBPATH
> accordingly,
> without having to copy around actual files.
>
>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Freemint-discuss mailing list
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freemint-discuss
>


-- 
MiKRO / Mystic Bytes
http://mikro.atari.org

Re: [Freemint-discuss] Installation path for shared libs

[David G. <dga...@gm...>]

2018-08-05 4:06 GMT+02:00 Thorsten Otto <ad...@th...>:
> Not that these are currently used much in FreeMinT (i think the recently added
> gemma.slb is the only one), but is there some standard/convention where to
> install shared libraries (the actual code that is loaded by Slbopen(), not any
> helper libraries you might need in your application).
>
> The automatic build process currently does not install them i think (only the
> development parts). And in the Makefile of eg. gemma, when you do a "make
> install", it will be installed to /mint/slb, and cpu-specific subdirectories.
>
> The question is: is that base-directory more or less standard? I've also seen
> pathes like /gemsys/slb, and  in MagiC they are usually in installed in /
> gemsys/magic/xtension.
>

I have them myself in /gemsys/slb, also I have placed ldg share
libraries inside /gemsys/ldg too. But I don't remember why I put them
there and if this is the standard. I thought that was from the times I
had a dual system MiNT/MagiC but from your comment above that MagiC
expects them in gemsys/magic/xtension I'm not sure anymore.
I guess that for MiNT only systems it makes sense to placed them
inside /mint/slb but I don't have a strong opinion about it.

> Also the names of the cpu-specific sub-directories are questionable. Currently
> the same names as the multi-lib directories from gcc are used (m68020-60,
> m5475 etc.). Since /mint (or /gemsys) are usually on the boot partition, and
> thus on a FAT filesystem, at least m68020-60 is not the best choice.
>

We should to take care about these things, there are also some network
drivers which doesn't fit with the 8+3 limit for FAT boot partition.

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[David G. <dga...@gm...>]

2018-08-04 22:52 GMT+02:00 Peter Slegg <p....@sc...>:
> I did have ntpdate in mint.cnf but it seems to have gone from the
> mint.cnf files in all the folders !
>
> Last year I was trying to get ntpd working, so maybe I removed it then.
>
> I have put ntpdate back again.
>
> # Timezone (mandatory)
> #~setenv TZ GMT-0BST,3.5.0,10.5.0
> setenv TZ GB
> #exec    u:\sbin\tzinit -l
> exec    u:\sbin\tzinit -u
> ntpdate pool.ntp.org
>

Do you have now the right time?

[Freemint-discuss] Installation path for shared libs

[Thorsten O. <ad...@th...>]

Not that these are currently used much in FreeMinT (i think the recently added 
gemma.slb is the only one), but is there some standard/convention where to 
install shared libraries (the actual code that is loaded by Slbopen(), not any 
helper libraries you might need in your application).

The automatic build process currently does not install them i think (only the 
development parts). And in the Makefile of eg. gemma, when you do a "make 
install", it will be installed to /mint/slb, and cpu-specific subdirectories.

The question is: is that base-directory more or less standard? I've also seen 
pathes like /gemsys/slb, and  in MagiC they are usually in installed in /
gemsys/magic/xtension.

Also the names of the cpu-specific sub-directories are questionable. Currently 
the same names as the multi-lib directories from gcc are used (m68020-60, 
m5475 etc.). Since /mint (or /gemsys) are usually on the boot partition, and 
thus on a FAT filesystem, at least m68020-60 is not the best choice.

And then: should the default libs (for plain 68000) be installed in the base 
directory, or also in a dedicated sub-directory, like the others? That would 
make it easier to switch configurations by just setting SLBPATH accordingly, 
without having to copy around actual files.

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 29 Jul 2018 17:41:47 , David Gálvez wrote:

2018-07-29 17:21 GMT+02:00 Peter Slegg <p....@sc...>:
> On Sun, 29 Jul 2018 16:55:39 , David GÃílvez wrote:
>>
>> The kernel is still in localtime mode. Did you edit the tzinit option
>> from "-l" to "-u" in mint.cnf?
>>
>
> No, that was without any changes.
>
> Changing it to -u and rebooting:
>
> bash-4.3# tzinit
> Current date and time: Sun Jul 29 15:18:25 2018
> Time zone in use: BST
> East of Greenwich Mean Time: 1:00:00
> Kernel clock mode: UTC
>
> bash-4.3# date
> Sun Jul 29 15:18:32 BST 2018
>
>
> It is currently 16:18 BST
>
>
It's very strange, are you sure the ntpdate command is getting the
time from the server successfully at boot?

--


I did have ntpdate in mint.cnf but it seems to have gone from the
mint.cnf files in all the folders !

Last year I was trying to get ntpd working, so maybe I removed it then.

I have put ntpdate back again.

# Timezone (mandatory)
#~setenv TZ GMT-0BST,3.5.0,10.5.0
setenv TZ GB
#exec    u:\sbin\tzinit -l
exec    u:\sbin\tzinit -u
ntpdate pool.ntp.org


Peter

Re: [Freemint-discuss] USB bug

[David G. <dga...@gm...>]

2018-08-01 22:25 GMT+02:00 Roger Burrows <an...@xp...>:
> Indeed, when the length is odd, the last bytes are handle incorrectly, but I
> wasn't able to figure out a simple way of forcing an odd length to a device for
> testing.  But that's a separate bug, and wouldn't cause any problems with
> memory sticks AFAICS.  The bug is that the entire sector is byte-swapped.
>
> To prove it, first I wrote a simple program that uses Rwabs() to read the boot
> sector of a FAT16 file system into both an unaligned & a word-aligned buffer.
> The results are different: all of the data in the unaligned buffer is
> byte-swapped.
>
> Having done that, I wrote another program using Rwabs() to write to a sector
> using both aligned and unaligned buffers, and to read back the contents into a
> word-aligned buffer.  Again, the bytes are swapped when the sector is written
> from the unaligned buffer.
>
> It's probably faster for you to write the programs yourself, but if you need
> them, I can dig them out.  Be warned, they are hacks of other programs so the
> source is a bit ugly, and they are written for LatticeC.
>

Thanks for the explanation! I'll fix this.

Re: [Freemint-discuss] USB bug

[Roger B. <an...@xp...>]

On 1 Aug 2018 at 11:58, David Gálvez wrote:

> Hi Roger, thanks for the bug report.
> 
> 2018-08-01 3:28 GMT+02:00 Roger Burrows <an...@xp...>:
> > Hi all,
> > There's a problem in isp116x-hcd.c (present in both the Ethernat &
> NetUSBee
> > controller drivers).  If the buffer is not word-aligned, the data is
> > byte-swapped by the read or write process.  Word-aligned buffers are OK. 
> The
> > error is in read_ptddata_from_fifo()/write_ptddata_to_fifo().
> >
> 
> The data should be byte-swapped, the word-align buffers do it too.
> Could you please be more specific? Perhaps you mean we shouldn't swap
> bytes in the latest two bytes in the data chunk when the length is an
> odd number?, lines 556 and 595 in the NetUSBee driver code.
> 
Indeed, when the length is odd, the last bytes are handle incorrectly, but I 
wasn't able to figure out a simple way of forcing an odd length to a device for 
testing.  But that's a separate bug, and wouldn't cause any problems with 
memory sticks AFAICS.  The bug is that the entire sector is byte-swapped.

To prove it, first I wrote a simple program that uses Rwabs() to read the boot 
sector of a FAT16 file system into both an unaligned & a word-aligned buffer.  
The results are different: all of the data in the unaligned buffer is 
byte-swapped.

Having done that, I wrote another program using Rwabs() to write to a sector 
using both aligned and unaligned buffers, and to read back the contents into a 
word-aligned buffer.  Again, the bytes are swapped when the sector is written 
from the unaligned buffer.

It's probably faster for you to write the programs yourself, but if you need 
them, I can dig them out.  Be warned, they are hacks of other programs so the 
source is a bit ugly, and they are written for LatticeC.

Roger

Re: [Freemint-discuss] USB bug

[David G. <dga...@gm...>]

Hi Roger, thanks for the bug report.

2018-08-01 3:28 GMT+02:00 Roger Burrows <an...@xp...>:
> Hi all,
> There's a problem in isp116x-hcd.c (present in both the Ethernat & NetUSBee
> controller drivers).  If the buffer is not word-aligned, the data is
> byte-swapped by the read or write process.  Word-aligned buffers are OK.  The
> error is in read_ptddata_from_fifo()/write_ptddata_to_fifo().
>

The data should be byte-swapped, the word-align buffers do it too.
Could you please be more specific? Perhaps you mean we shouldn't swap
bytes in the latest two bytes in the data chunk when the length is an
odd number?, lines 556 and 595 in the NetUSBee driver code.

[Freemint-discuss] USB bug

[Roger B. <an...@xp...>]

Hi all,
There's a problem in isp116x-hcd.c (present in both the Ethernat & NetUSBee 
controller drivers).  If the buffer is not word-aligned, the data is 
byte-swapped by the read or write process.  Word-aligned buffers are OK.  The 
error is in read_ptddata_from_fifo()/write_ptddata_to_fifo().

Since this hasn't been fixed, I assume that people only use word-aligned 
buffers, which isn't too surprising.  I won't be directly proposing a fix, 
since I don't use freemint, but I wanted to post the info here, since it is a 
data integrity problem.

Roger

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[David G. <dga...@gm...>]

2018-07-29 17:21 GMT+02:00 Peter Slegg <p....@sc...>:
> On Sun, 29 Jul 2018 16:55:39 , David Gálvez wrote:
>>
>> The kernel is still in localtime mode. Did you edit the tzinit option
>> from "-l" to "-u" in mint.cnf?
>>
>
> No, that was without any changes.
>
> Changing it to -u and rebooting:
>
> bash-4.3# tzinit
> Current date and time: Sun Jul 29 15:18:25 2018
> Time zone in use: BST
> East of Greenwich Mean Time: 1:00:00
> Kernel clock mode: UTC
>
> bash-4.3# date
> Sun Jul 29 15:18:32 BST 2018
>
>
> It is currently 16:18 BST
>
>
It's very strange, are you sure the ntpdate command is getting the
time from the server successfully at boot?

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Peter S. <p....@sc...>]

On Sun, 29 Jul 2018 16:55:39 , David Gálvez wrote:
> 2018-07-29 14:23 GMT+02:00 Peter Slegg <p....@sc...>:
> >
> >
> > This looks wrong:
> >
> > bash-4.3# tzinit
> > Current date and time: Sun Jul 29 12:18:04 2018
> > Time zone in use: BST
> > East of Greenwich Mean Time: 1:00:00
> > Kernel clock mode: localtime
> > bash-4.3# date
> > Sun Jul 29 12:18:07 BST 2018
> >
>
> The kernel is still in localtime mode. Did you edit the tzinit option
> from "-l" to "-u" in mint.cnf?
>

No, that was without any changes.

Changing it to -u and rebooting:

bash-4.3# tzinit
Current date and time: Sun Jul 29 15:18:25 2018
Time zone in use: BST
East of Greenwich Mean Time: 1:00:00
Kernel clock mode: UTC

bash-4.3# date
Sun Jul 29 15:18:32 BST 2018


It is currently 16:18 BST


Peter

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[David G. <dga...@gm...>]

2018-07-29 14:23 GMT+02:00 Peter Slegg <p....@sc...>:
>
>
> This looks wrong:
>
> bash-4.3# tzinit
> Current date and time: Sun Jul 29 12:18:04 2018
> Time zone in use: BST
> East of Greenwich Mean Time: 1:00:00
> Kernel clock mode: localtime
> bash-4.3# date
> Sun Jul 29 12:18:07 BST 2018
>

The kernel is still in localtime mode. Did you edit the tzinit option
from "-l" to "-u" in mint.cnf?

Re: [Freemint-discuss] Fwd: Re: Timezone and timestamp

[Thorsten O. <ad...@th...>]

On Sonntag, 29. Juli 2018 14:23:01 CEST Peter Slegg wrote:
> bash-4.3# tzinit
> Current date and time: Sun Jul 29 12:18:04 2018
> Time zone in use: BST
> East of Greenwich Mean Time: 1:00:00
> Kernel clock mode: localtime
> bash-4.3# date
> Sun Jul 29 12:18:07 BST 2018

That looks indeed wrong, it is still using the "Factory" defaults. It should 
look like this:

Current date and time: Sun Jul 29 16:20:24 2018 
Time zone in use: CEST 
East of Greenwich Mean Time: 2:00:00 
Kernel clock mode: localtime

Re: [Freemint-discuss] Timezone and timestamp

[Thorsten O. <ad...@th...>]

On Sonntag, 29. Juli 2018 14:34:09 CEST Peter Slegg wrote:
> I had assumed Mint took care of the
> time change.

Mint does not use the TZ environment variable, nor does mintlib. It only uses 
information from the timezone database. But Thing does not use mintlib, and 
the simple implementaton in Pure-C's libraries only uses a single timezone 
offset, which is can be initialized using the TZ variable. But remember that 
this is an ancient way of such handling. The TZ environment variable is only 
valid for the current local time, it does not work for arbitrary file system 
dates.

>rsync doesn't recognise the time changes either. It always copies files 
>because it thinks there is a 1hr difference in the filestamp.

That seems to be another issue then. rsync should use mintlib.

Re: [Freemint-discuss] Timezone and timestamp

[Peter S. <p....@sc...>]

On Fri, 27 Jul 2018 19:41:24 , Thorsten Otto <ad...@th...> wrote:
> On Montag, 26. März 2018 15:32:28 CEST Peter Slegg wrote:
> > but in Thing they are shown with a time of 1 hour ahead.
>
> I think this is because Thing is compiled by Pure-C, which does not have a
>
> complete timezone database. Sometimes setting the TZ environment variable
>
> helps, but not always, and you have to remember to change that accordingly
>
> when switching to/from summertime.
>
>

I haven't been changing the TZ for summer, I had assumed Mint took care of the
time change.

rsync doesn't recognise the time changes either. It always copies files because
it thinks there is a 1hr difference in the filestamp.

If I rsync a folder in March (GMT) and then rsync it is June (BST) it will copy
the file again but the file hasn't changed.

It gets confusing because you never know which is a the real date-time.


Peter