[Info-vax] EU will abandon daylight savings time in 2021

Jan-Erik Söderholm jan-erik.soderholm at telia.com
Wed Apr 3 14:59:53 EDT 2019


Den 2019-04-03 kl. 20:00, skrev Stephen Hoffman:
> On 2019-04-03 17:37:06 +0000, Jan-Erik Sderholm said:
> 
>> We have some local timestamps that has to be converted to GMT/UTC before 
>> sent to another system, and these are both from "winter time" and "summer 
>> time". We can of course hardcode the dates for the switches and compare, 
>> but it would be nice if the rule
>> could be used...
> 
> You can ask for the current timezone through various APIs, if that's what 
> you're after.  But asking for the timezone setting is probably 
> unnecessary.  The calls will use the current settings.
> 
> More to what you're probably after, the related calls used for fetching the 
> time are the DTSS calls that were integrated with OpenVMS a while back 
> (utc_ascgmtime, utc_vmsgmtime, etc), or the C standard library calls (e.g. 
> gmtime), or use the system services including $GETUTC or SYS$TIMCON or such.
> 

OK, right. I'll take a second look at the Python routines, that is where
all this happens.

> For transmitting the time, there are text-formatting routines.

It is transmitted as "Unix epoch" format, no problem with that.
We can easily subtract 3600 or 7200 from the epoch-number of seconds.

> Parts of the following doc are somewhere well out past wrong—lib$subx is 
> not a reliable means of calcuating an interval, even as is shown for the 
> OpenVMS quadword times—but this old doc will give you pointers to some of 
> the available APIs:
> https://www.itec.suny.edu/scsys/vms/OVMSDOC073/v73/5841/5841pro_072.html
> 
> Here are the DTSS docs:
> http://h30266.www3.hpe.com/odl/i64os/opsys/vmsos84/4493/4493pro_016.html#port_api 
> 

OK, will check that out. Thanks.


> 
> Related:
> https://en.wikipedia.org/wiki/ISO_8601
> 
> 




More information about the Info-vax mailing list