UEdit time insert (F7 key) suddenly off by 1 hour

[martine]

Greetings,

for many years I have been using UltraEdit (currently still at v.10.10), and have all the time routinely used the F7 key to insert datetime stamps.

Now, all of a sudden, the inserted time is off (slow) by one hour:
e.g. UE says 02.08.2006 08:45 when the correct time is 02.08.2006 09:45.
(My time zone is currently EEST Eastern European Summer Time, which is GMT+3h)

Naturally, I have at once verified in the Control Panel (Win XP Pro) that the system time (from which UE gets that time stamp, I think) is still correct.

The problem persists even after rebooting the system (next day).
And there weren't any changes in the system during the last time.

It does look suspiciously like a daylight saving time issue, but if the system gets that right, why not UE, too?

And at the moment, DST is still firmly active here in Europe as well as (I think) in the US; so some "premature" switching over to standard (winter) time can't be the reason either.

I have already contacted UE support, but they so far just state that it does work for them, that UE simply uses the system time (in Short Format), and that they can't think of any reason why it doesn't do so any more for me; nor can they give any advice about how to proceed.

Has anyone else ever observed this strange phenomenon?

All hints and pointers will be much appreciated!
Admittedly, it's not an overly vital issue, but I want my timestamp back!

Cheers,
Martin

[Bego]

Hi,

works fine on my UE 12.10a ....

Are you sure you don't use an "overwriting" Macro put on the key "F7" ?
Simply call the function via "edit-menu" and check again.

Sry, no better tips.

rds Bego

[Mofi]

I think, I can explain that because I feel angry since years how Microsoft as implemented the daylight saving time mechanism. If you double click on the hour in the taskbar you will see the dialog to specify the date and time. But there is also a second tab named Time Zone (and on WinXP after a few seconds you will also see a third tab). There you cannot only specify the time zone, you can also enable or disable Automatically adjust clock for daylight saving changes.

This option has a dramatic effect on all times on your computer, the current system time and also all file times of files on NTFS drives (local and network NTFS drives).

During the standard time period (winter time), you will not see any change of the times independent of the state of this option. But during the summer time period toggling this option let's me (and maybe also you) think the MS developers have a little bit drunken too much beer as they implemented it.

If you turn off the option during summer time period, the system time suddenly decreases by 1 hour. Also ALL files and directories on NTFS drives have now changed the file time by -1 hour. Yes, that's unbelievable. Suddenly a file is not modified last time anymore at 08:45:23, now it is modified last time at 07:45:23???

In our company we set the date of all files of a program to the release date and the hour is the version number. That's also done by many other companies like Microsoft itself or IDM or the program Total Commander. But the version number encoded in the file time changes according to this setting and which time period is actually active.

Many further problems exist because of this in my point of view crazy file time handling. Think about synchronizing files on a NTFS drives with files on a FAT or FAT32 drive or within a ZIP, RAR, ARJ, ... archive. That's the reason why Total Commander has the option to ignore file time differences of exactly 1 hour (and 1 second).

Or you modify files in the winter period, but pack the files into an archive in the summer period and distribute the archive. Well, the user who unpacks the archive will maybe have the files with the same file time as you or not depending on time period, this option and the file system. It's also possible to increase the hour of the files permanently by doing following during summer time period:

1) Turn on the option.
2) Pack the files into a new archive.
3) Turn off the option.
4) Unpack the files from the archive to an NTFS drive.

Repeat these 4 steps several times and the file time is increased by 1 hour at every repeat.

I think, the best would be to turn this option off in the whole company LAN on all computers and correct the time at every summer time begin and end manually on every computer OR only on the login server (and the other servers) and all other computers get the time with the "net time" command when the user of the computer logs in into the companies network which is anyway already done in the most companies during the login procedure.

In your case first look at this option. Is it checked now - we have summer time? If your computer is part of company network, ask the person who is responsible for the network which setting this option should have in your company.

Next search in the list of environment variables if you have one named TZ and if so, if it also has the correct value for your time zone with/without daylight saving time. This environment variable is used by all time handling routines implemented in the kernel of Windows. See also Wikipedia Time zone and the pages linked there and also _tzset at Microsoft's developer network.

I personally would vote for put an end to the daylight saving time nonsense. The whole world should use the whole year only one time. I have read many about the DST because I'm personally affected by this daylight saving time nonsense because I'm a protocol firmware programmer. So I have read much about daylight saving times in all there excesses and what problems occur with it in industry (railroad and air traffic, electrical power networks, telephone and data networks, ...). Most people don't know how many problems occur because of the DST nonsense. Example train traffic: all trains must stop for 1 hour in the next station in the night when the summer time ends and in the night when it begins all night trains reach their end station (and other stations) 1 hour delayed. Hopefully the passengers have taken this not preventable delay into consideration if they have to continue their travel with an other means of transport which is not delayed because it was not on the way during time switch.

[martine]

Thanks for the replies!

But:

> works fine on my UE 12.10a .
So it did until a few days ago for my UE 10.10

And...

-- I do not have any macros assigned to the F7 key, and in any case, I did try insertion via Edit menu as advised, with the same result: time is still one hour off (e.g. 18:00h instead of 19:00h)

-- Yes, I do know about all these oddities of the DST and especially file date handling in Windows. But still, as reported, the system time works perfectly well, so why does UE suddenly "see" another time???

-- And yes, I, too, did suspect the TZ environment variable (which indeed I do have), but again, it looks perfectly OK, and it must be if the system time works correct, or?

Any other hints? This is really strange...

In fact, is UE a real Windows application, talking directly to Windows system functions, or is it actually still a DOS app just wrapped into Windows? Would that make a difference anyway? Do only DOS app.s utilize the TZ variable?

Cheers,
Martin

[Mofi]

UltraEdit is a real Windows application even certified by Microsoft - see IDM Computer Solutions, Inc. Earns Certified Partner Status In Microsoft Partner Program.

UltraEdit uses the Time Functions of the Windows kernel. The TZ variable is also used by the Windows kernel time functions and not only by DOS applications.

And yes, I, too, did suspect the TZ environment variable (which indeed I do have), but again, it looks perfectly OK, and it must be if the system time works correct, or?

No, it must not be. The clock in the system tray can show the correct time even when the TZ variable is wrong. I have tested this before writing my first post. If TZ is set wrong and/or the Automatically adjust clock for daylight saving changes is not checked and the system time is set manually via the dialog or by DOS command "time" or via "net time" or via NTP (by default active for WinXP systems - Internet Time!), you can see the correct time in the system tray, but Windows kernel time functions returns wrong localized times.

Suggestion: Delete or rename your TZ variable, restart Windows, look at the clock in the system tray and check the insert Date/Time function of UltraEdit again.

According to _tzset function and Time zone acronyms and abbreviations your TZ variable should have following value: EET+2GDT and at the time zone tab of the "date and time" control panel setting the correct time zone should be selected and the Automatically adjust clock for daylight saving changes must be checked.

Note: According to _tzset function explanation it looks like the Windows time functions don't support time zone strings with 4 characters like EEDT or EEST.

Why do you have a TZ environment variable? Do you have DOS programs which need it? The Windows kernel time functions automatically use the control panel time zone settings when no TZ variable exists.

[martine]

Hello,

(and sorry for the delay of this reply -- so many things to follow up...)

Indeed, removing the TZ variable did the trick! After that, the UE time stamp is now correct again.

No, it must not be. The clock in the system tray can show the correct time even when the TZ variable is wrong.

Aha! That's what I didn't know! So at least I learnt something new.
Many thanks for taking the time (! ) to explain it so thoroughly; this is indeed useful knowledge!

Why do you have a TZ environment variable? Do you have DOS programs which need it?

Yes, exactly: I am still a fond user of the old but good Ephem program (doesn't seem to have its own home page, but you can find a download link in the author's CV)

That program uses a TZ variable (but of the format like e.g. "TZ=-3", so it's different from what you describe, apparently), which so far has never caused me grief. But recently I played around with some Python routines, converting Unix "epoch" time (seconds since 1.1.1970) to other formats, and I suspect this may possibly have interfered with the TZ variable, too.

Anyhow, we learn something new every day!

Thanks again for your help!
Schöne Grüße aus Finnland,
Martin