[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